Seminario Final Calidad Equipo #5

Universidad Tecnológica de La Habana “José
Antonio Echeverría”
Facultad de Ingeniería Informática
Seminario Final Calidad
Equipo #5: Pruebas de software: Herramienta Postman
Autores:
Daniela Laura Vera Lavigne
Gilbert Luis Pino Gómez
Luis Enrique Castillo Sierra
Miguel Alejandro Benítez Barro
Alejandro Leyva Caro
Abel Rodríguez Montalvo
La Habana, Cuba
2021
1
Índice
Introducción...................................................................................................................................1
1. Documentación del proyecto seleccionado...................................................................2
2. Fundamentos básicos de las pruebas de software......................................................4
2.1 Qué son las pruebas de software..............................................................................4
2.2 Por qué son importantes las pruebas de software...............................................5
2.3 Objetivo y características de las pruebas de software........................................5
3. Herramientas de pruebas de software: Postman..........................................................7
3.1 Tipos de pruebas...........................................................................................................8
3.2 Selección del tipo de prueba....................................................................................12
4. Diseño del caso de pruebas.............................................................................................13
Conclusiones...............................................................................................................................19
Referencias Bibliográficas........................................................................................................20
Índice de Tablas
Tabla 1 - Diseño caso de prueba "Insertar cursos"..................................................................13

Tabla 2 - Diseño caso de prueba "Insertar cursos".................................................................13
Tabla 6 - Diseño caso de prueba "Insertar profesor"...............................................................17
Tabla 7 - Diseño caso de prueba "Insertar profesor"..............................................................17
Índice de Ilustraciones
Ilustración 1 - Diagrama de caso de uso del sistema 3

Ilustración 2 - Pantalla principal Postman 8
Introducción
El desarrollo de software es una actividad que está sujeta a los errores humanos,
por tanto, es probable encontrarse en cualquier desarrollo con defectos, errores y
fallas. Para tratar de evitar esas situaciones al máximo existen ya definidas
metodologías de desarrollo que si bien no garantizan la eliminación total de
errores si disminuyen altamente la probabilidad de falla. Pero aún así y por más
que se quieran evitar este tipo de sucesos, se dificulta ya que son inesperados, es
allí donde cobra importancia un adecuado proceso de pruebas de software que
permita certificar desde el punto de vista de la calidad un producto de software, si
bien es una tarea que necesita de diversos recursos como el esfuerzo, planeación,
organización, documentación y tiempo no se debe tomar como un impedimento,
sino como una inversión que se verá retribuida en la satisfacción del usuario final o
cliente.
La facultad de Ingeniería Informática, de la Universidad Tecnológica de La Habana
José Antonio Echeverría (Cujae), realiza varios trabajos de informatización. Uno
de los cuales está involucrada es el control de alumnos ayudantes, encargados de
ayudar a profesores para impartir una asignatura, en la cual el estudiante presente
buen índice académico.
El software a desarrollar para esta problemática formará parte de un conjunto de
soluciones que se han desarrollado y que se están desarrollando como parte del
Proyecto CUJAE, como propósito de informatización de los procesos de la
universidad. Para ello, se ha definido que del lado del servidor se implemente en
PHP y que se utilice el framework Yii, por las facilidades que ofrece, con el gestor
de base de datos Postgres. Adicionalmente, resulta necesario que en el servidor
esté instalada la biblioteca juzzle.http para que sea posible hacer peticiones entre
servidores. Para manejar información respecto a los estudiantes, se usará
SIGENU y un software conocido como Directorio para la información de los
profesores.
En este trabajo se estará abordando acerca de las pruebas de software,
principalmente sobre la herramienta de software Postman, y su uso en el software
a desarrollar como parte del Proyecto CUJAE, en la Universidad Tecnológica de
La Habana.
1
1. Documentación del proyecto seleccionado
Actualmente como parte del proceso de informatización de la CUJAE se realizará
un software donde se desarrollará un sistema de gestión para el control de
alumnos ayudantes. En este se podrá controlar todo respecto a estos estudiantes,
como su pago y su índice académico, que le permite o no seguir impartiendo dicho
rol.
Un sistema de gestión no es más que el conjunto de reglas y principios
relacionados entre ellos con un orden, para ayudar a la gestión de procesos
generales de una institución u organización. Este permite establecer una política,
unos objetivos y alcanzarlos. Con este sistema de gestión se puede obtener
ventajas para manejar la información con la que se trabaja y aportar en un futuro
mejores decisiones.
En la Facultad de Ingeniería Informática de la Universidad Tecnológica de La
Habana José Antonio Echeverría (Cujae) se contribuye al Proyecto CUJAE dentro
del cual se realiza un conjunto de soluciones que se han desarrollado y que se
están desarrollando, con el propósito de ir informatizando los diferentes procesos
sustantivos de la universidad.
Para la creación de este software se utilizarán aplicaciones y tecnologías muy
conocidas a nivel mundial, como el lenguaje PHP especialmente adecuado para el
desarrollo web, puede ser incrustado en HTML y favorece a la conexión entre los
servidores y la interfaz de usuario, además de ser de código abierto. El framework
Yii es otro elemento presente en este trabajo el cual está orientado a PHP y nos
permite desarrollar aplicaciones web a gran escala, una característica fundamental
es su reutilización. En este proyecto también se utilizará la biblioteca juzzle http, el
sistema SIGENU donde se almacena gran cantidad de información de los
estudiantes y el software llamado Directorio que mantiene contenido actualizado
sobre los profesores.
Sobre este trabajo no se tienen precedentes, lo cual serán las primeras
impresiones acerca de este tema.
En el control de alumnos ayudantes existen tres actores fundamentales que son:
el decano, SIGENU y el Departamento de Contabilidad y Finanzas. Todo empieza
cuando el decano define el proceso de selección de alumnos ayudantes, para ello
el jefe de departamento envía una lista de propuestas para jefe de alumno
ayudante, el cual es un profesor. Luego se realiza la selección de nuevos alumnos
ayudantes donde el jefe de alumnos ayudantes solicita una propuesta a los
profesores, este debe informar al alumno para que le comunique su decisión. El
consejo de dirección analiza al estudiante apoyados en SIGENU que le brindará
información sobre los resultados docentes del estudiante. Luego se les informa a
los jefes de departamentos sobre los alumnos ayudantes. La etapa del alumno
ayudante debe ser actualizada en septiembre, el jefe de departamento es el
encargado de esto, quien se apoya en información que le brinda la secretaria
2
docente y el vicedecano docente. Al término de esta operación el estudiante
puede continuar como alumno ayudante o darle baja (una de las causas de baja
podría ser el índice académico del estudiante). El decano solicita un plan de
trabajo para los estudiantes que cumplan este rol, para ello tendrá la ayuda del
tutor del estudiante, este último realiza el plan de trabajo de acuerdo a lo que
realizará el alumno ayudante, puede estar implicado en docencia o grupo de
investigación. Se le creará un plan de estudio, el cual debe ser aceptada por el
rector de la universidad y quedar archivado por el secretario docente. Por último, y
no menos importante, el decano realiza la solicitud de pago para pagar el estímulo
acordado en la resolución Nº 15/08 sobre el pago de alumnos ayudantes, donde el
jefe de alumnos ayudantes realiza un registro de altas y bajas para entregar al
vicedecano económico y entregarlo al Departamento de Contabilidad y Finanzas.
Un estudiante puede solicitar su baja si ya no quiero cumplir con este rol, el jefe de
alumnos ayudantes actualiza su situación en SIGENU y es notificado al tutor y al
propio estudiante sobre la actualización. Asimismo, puede decidir si continuar o no
cuando el decano solicita la baja de alumnos ayudantes, siempre y cuando cumpla
con los requisitos.
A continuación, en la ilustración 1 se muestra el diagrama de caso de uso del
sistema donde se representan los actores que hacen uso del sistema y lo qué
hacen.
Ilustración 1 - Diagrama de caso de uso del sistema
3
2. Fundamentos básicos de las pruebas de software
2.1 Qué son las pruebas de software
El ISTQB (International Software Testing Qualifications Board), una organización
sin ánimo de lucro creada en el año 2002 por empresas, instituciones,
organizaciones y personas especializadas en el campo de las pruebas y la
industria del software, define las pruebas como [1]:
“El proceso que consiste en todas las actividades del ciclo de vida, tanto estáticas
como dinámicas relacionadas con la planificación, preparación y evaluación de
productos de software y productos relacionados con el trabajo para determinar que
cumplen los requisitos especificados, para demostrar que son aptos para el
propósito y para detectar defectos”.
Cem Kaner, profesor de Ingeniería de software en el instituto tecnológico de
Florida, es uno de los defensores y principales gurús de las pruebas de software,
las define como [2]:
“Las pruebas de software son la investigación empírica y técnica realizada para
facilitar a los interesados información sobre la calidad del producto o servicio bajo
pruebas”.
Kaner introduce la figura del técnico que mediante la investigación aportará datos
sobre la calidad del producto y no se centrará únicamente en la detección del fallo.
Edsger W. Dijstra, científico de la computación entre cuyas contribuciones a la
ciencia esta ‘la solución del problema del camino más corto’, también conocido
como el algoritmo de Dijstra, define el proceso de pruebas como [3]:
“Las pruebas de software pueden ser una manera muy eficaz de mostrar la
presencia de errores, pero son totalmente inadecuadas para mostrar su ausencia.”
Todas y cada una de estas definiciones tienen algo en común, todas se centran en
mayor o menor manera en la detección de errores. Para terminar de entender las
pruebas debemos diferenciar los términos error, fallo y defecto. Estos conceptos
están relacionados entre sí, pero tienen significados diferentes. Para comprender
estas palabras y por ende las pruebas, vamos a ver como las define el ISTQB [1]:
“Una persona puede cometer un error que a su vez puede producir un defecto en
el código de programa o en un documento. Si se ejecuta un defecto en el código,
el sistema puede no hacer lo que debiera (o hacer algo que no debiera), lo que
provocaría un fallo. Algunos defectos de software pueden dar lugar a fallos, pero
no todos los defectos lo hacen.”
También es importante conocer la diferencia entre error, defecto y fallo. Así se
tiene que [3, 4]:
 Error: está provocado por la acción humana, por ejemplo, el error lo provocará
el desarrollador que realizará una incorrecta interpretación de un método del
programa que producirá un resultado no esperado.
 Defecto: provocado por un error de implementación, por ejemplo, el defecto lo
provocará el haber utilizado el operador “x + y > z” en vez de “x + y => z”
4
 Fallo: al ejecutar el programa con un defecto obtendremos resultados no
deseados, por ejemplo, cuando el resultado de la suma de los dos
componentes fuese igual, no obtendríamos los mismos resultados al
compararlos con las sentencias indicadas anteriormente. En sistemas muy
complejos, como pueden ser una lanzadera espacial o una central eléctrica,
pueden llegar a producir efectos catastróficos.
2.2 Por qué son importantes las pruebas de software
Hoy en día, forman parte de nuestras vidas multitud de sistemas que contienen
software, como por ejemplo los coches, Smartphone, sistemas de producción de
energía, programas bancarios, etc.
A día de hoy el funcionamiento de casi todas las empresas depende en gran
medida del software, ya sea por el sistema de finanzas de dicha empresa o por la
maquinaria que lleva a cabo la fabricación de los productos, por lo que las
empresas dependen del funcionamiento del software y de que éste pueda llegar a
causar grandes fallos como los mencionados anteriormente que llevan a la pérdida
de miles de millones de euros. No a todas las empresas les afectan de la misma
manera los fallos producidos en el software, por lo que tenemos que evaluar los
riesgos de éste, ya que pueden llegar a producir pérdidas irreparables [4-6].
Es por ello que las pruebas de software son una de las actividades más
importantes y fundamentales en el desarrollo de un proyecto, ya que posibilita los
procesos, métodos de trabajo y herramientas necesarias para garantizar la calidad
de cualquier desarrollo [5, 7].
Con el fin de poder detectar a tiempo cualquier error y garantizar que el producto
cumple con todas las premisas establecidas, el testing debe existir en todas las
fases de un proyecto: desde la toma de requerimientos en cliente, pasando por las
reuniones de seguimiento, hasta la entrega del producto final. Es más, un
proyecto carente de este proceso en todas sus fases acaba generando un mayor
coste económico y un mayor esfuerzo durante la fase de pruebas [6, 7].
2.3 Objetivo y características de las pruebas de software
Los principales objetivos de las pruebas son los siguientes [3, 5, 6]:
 Encontrar el mayor número de defectos en el código para que se resuelvan
y eliminarlos.
 Asegurar que el producto funciona tal y cómo se ha definido en los
requisitos (Control de Calidad).
 Dar información al cliente de los defectos que no se han podido eliminar del
producto final.
 Proporcionar al producto final un grado mayor de calidad.
 Para cumplir estándares: Otro motivo por el cual las pruebas son
necesarias es que los estándares de la industria muchas veces exigen la
existencia de fases de pruebas en el proceso de desarrollo.
Entre sus características más importantes están [3, 6, 7]:
5
 Alta probabilidad de encontrar un error. El ingeniero de software debe tener
un alto nivel de entendimiento de la aplicación a construir para poder
diseñar casos de prueba que encuentren el mayor número de defectos.
 No debe ser redundante. Uno de los objetivos de las pruebas es encontrar
el mayor número de errores con la menor cantidad de tiempo y esfuerzo
posibles, por lo cual no se deben diseñar casos de prueba que tengan el
mismo propósito que otros, sino que se debe tratar de diseñar el menor
número de casos de prueba que permitan probar adecuadamente el
software y optimizar los recursos.
 No debería ser ni demasiado sencilla ni demasiado compleja.
6
3. Herramientas de pruebas de software: Postman
Las pruebas de software son sin duda uno de los conceptos más necesarios
para garantizar la calidad de nuestro software. Una de las herramientas más
utilizadas para la realización de pruebas es Postman.
Postman nace como una herramienta que principalmente permite crear peticiones
sobre APIs de una forma muy sencilla y poder, de esta manera, probar las APIs.
Todo basado en una extensión de Google Chrome. El usuario de Postman puede
ser un desarrollador que esté comprobando el funcionamiento de una API para
desarrollar sobre ella o un operador el cual esté realizando tareas de
monitorización sobre un API [8-10].
Alrededor de la idea de testear las APIs, Postman ofrece un conjunto de utilidades
adicionales para poder gestionar las APIs de una forma más sencilla. Es por ello
que proporciona herramientas para documentar los APIs, realiza una
monitorización sobre las APIs, crea equipos sobre un API para que trabajen de
forma colaborativa, convirtiendo así a Postman plataforma de desarrollo de APIs
que se basa por un modelo de desarrollo API First [8-10].
A día de hoy Postman ofrece aplicaciones Windows, Linux y Mac, así como un
módulo colaborativo para equipos basado en Cloud.
Con Postman se puede realizar desde test manual, hasta el más exploratorio, que
te ayuda a conocer si ciertos endpoints funcionan como se espera o que
información contienen, hasta tests automatizados que se pueden ejecutar desde la
línea de comandos e integrar en el proceso de CI/CD [8-10].
Esta herramienta está diseñada principalmente para probar las API del tipo REST.
Posee una interfaz de usuario muy fácil y agradable. Ofrece una gran cantidad de
funcionalidades, por ejemplo, permite realizar cualquier tipo de llamada a la API
(REST, SOAP o simplemente HTTP) e inspeccionar fácilmente las respuestas.
También las respuestas se pueden analizar en función del tipo de respuesta
(JSON, XML o HTML) [8-10].
7
Ilustración 2 - Pantalla principal Postman
Como se puede observar en la ilustración 2, en Postman se trabaja con

colecciones de API. Estas colecciones funcionan como agrupadores de peticiones,
lo que permite ordenar recursos y servicios y probar cada petición de una forma
más rápida y fácil.
Con esta herramienta se pueden automatizar distintos tipos de pruebas.
3.1 Tipos de pruebas
Postman permite automatizar las pruebas de API e integrar la colección con
canalizaciones de CI/CD. Se puede automatizar pruebas unitarias, pruebas
funcionales, pruebas no funcionales, pruebas de integración y pruebas de
regresión.
Estas pruebas se deben realizar a un nivel prudente, según:
 la complejidad de la aplicación,
 la cantidad de tráfico que la aplicación recibe, y
 el tamaño del equipo.
De manera general, lo primero que se debe tener en cuenta es que existen
pruebas de software manuales y pruebas de software automatizadas.
Las pruebas manuales son un tipo de prueba de software donde los analistas de
certificación ejecutan manualmente los casos de prueba definidos sin usar ninguna
herramienta o script de automatización. Es la más primitiva de todos los tipos de
prueba y ayuda a encontrar errores en el sistema de forma muy puntual.
Las pruebas manuales significan probar una aplicación o sistema manualmente
8
con pruebas puntuales para garantizar que un sitio web o una aplicación funcionen
correctamente según los requerimientos y condiciones que se definen.
Los objetivos principales para ejecutar una prueba manual es verificar el diseño, la
ortografía, la funcionalidad y el rendimiento de la interfaz del sistema, pero
también es intentar corromperlo para ver si existe algún punto ciego que se pueda
considerar como una vulnerabilidad [10-13].
Las pruebas automatizadas son una clasificación de las pruebas manuales donde
aquí no aplica ninguna clase de intervención humana en la ejecución. Cuando se
trata de construir una prueba automatizada se debe de tener en cuenta todas
aquellas funcionalidades críticas en el sistema para poder aprovechar por
completo su finalidad, no se recomienda construir este tipo de pruebas sobre
sistemas que tiene que ver con solamente contenido o diseño, ya que esta no es
la finalidad de esta pruebas [10-13].
La finalidad de este tipo de pruebas es la de ser ejecutada sin intervención
humana cierta cantidad de veces y para temas de regresión o ejecución de un
sistema, siempre y cuando sea configurable y accesible, con una gran cantidad de
reportes fácil de entender que se genera después de la ejecución de un sistema
[10-13].
Las Herramientas más usadas son: Selenium, Serenity, cucumber, Katalon,
Appium Studio, Postman, SOAP UI, Java, etc.
Estas pruebas automatizadas se pueden realizar en el FrontEnd y en el BackEnd.
A continuación, se documentan las pruebas para el Backend.
Las pruebas automatizadas en el BackEnd es construir unos scripts apuntados
directamente a los servicios que expone un back, de cualquier tipo de petición ya
sea Get, Post, Put, Delete, etc, a su vez también revisar sus tipos de estados ya
sea 200, 400 o 500 etc, y que cumpla con sus diferentes tipos de validaciones
según los requerimientos del sistema [13].
Las herramientas más usadas son: Selenium, Postman, SOAP UI, Java, etc.
¿En qué momento ejecutar?
Principalmente se tiene en cuenta en la ejecución de servicios Rest o Soap, en
cualquier servicio.
Existen otros tipos de pruebas de software. A continuación, se muestran algunas
de estas pruebas que se pueden realizar en la herramienta Postman [3, 4, 10, 14].
 Pruebas unitarias
Las pruebas unitarias son a bajo nivel (cercanas al código fuente de la
aplicación).
Este tipo de testing consiste en probar de forma individual las funciones y/o
métodos (de las clases, componentes y/o módulos que son usados por el
software).
Debido a lo específicas que son, generalmente son las pruebas automatizadas de
menor coste, y pueden ejecutarse rápidamente por un servidor de continuous
integration (integración continua).
9
Más detalles acerca de las pruebas unitarias:
 Cuando se planean y escriben pruebas unitarias, se debe aislar la
funcionalidad hasta un punto en que no se pueda desglosar más, y entonces
escribir pruebas a partir de ello. Justamente, el nombre de este tipo de testing
hace referencia a una "unidad de código", que es independiente del resto.
 Estas pruebas verifican que el nombre de la función o método sea adecuado,
que los nombres y tipos de los parámetros sean correctos, y así mismo el tipo y
valor de lo que se devuelve como resultado.
 Dado que las pruebas unitarias no deben tener ningún tipo de dependencia, se
suele reemplazar los llamados a APIs y servicios externos por funcionalidad
que los imite (para que no exista interacción que vaya más allá de la unidad
que está siendo probada).
En muchos casos inclusive se suele reemplazar las consultas a bases de datos,
de modo que la prueba se enfoque en operar a partir de los valores de entrada, sin
depender de ninguna fuente externa.
 Si no es factible aislar el uso de bases de datos de las pruebas unitarias, es
importante tener en cuenta el rendimiento y buscar optimizar las consultas.
Esto es importante, porque si las pruebas unitarias son de larga duración,
resultará incómodo ejecutarlas y ralentizará significativamente los tiempos de
desarrollo.
Cuando se habla de Test Driven Development (desarrollo guiado por pruebas),
se hace referencia a unit tests. Es decir, se usan pruebas de este tipo
como especificaciones de lo que nuestro código debe hacer.
 Pruebas Funcionales:
Las pruebas funcionales, como su propio nombre indica, se centran en validar la
funcionalidad del producto o componente.
El diseño de estas pruebas se realiza en base a los requisitos y casos de uso,
generalmente documentados, de un sistema o característica. Las pruebas
funcionales pueden ser diseñadas para todos los niveles de pruebas.
Estas pruebas son consideradas de caja negra, puesto que el usuario que diseña,
desarrolla y ejecuta la prueba no tiene por qué conocer la lógica ni la estructura
interna del programa.
A veces existe cierta confusión entre "integration tests" y "functional tests", ya que
ambos requieren que múltiples componentes interactúen entre sí.
La diferencia es que,
 una prueba de integración puede simplemente verificar que las consultas a una
base de datos se ejecuten correctamente,
 mientras que una prueba funcional esperaría mostrar un valor específico a un
usuario, en concordancia a lo definido por los requerimientos del producto.
 Pruebas de integración
10
Las pruebas de integración verifican que los diferentes módulos y/o servicios
usados por nuestra aplicación funcionen en armonía cuando trabajan en conjunto.
Por ejemplo, pueden probar la interacción con una o múltiples bases de datos, o
asegurar que los micro servicios operen como se espera.
Las pruebas de integración son típicamente el paso siguiente a las pruebas
unitarias.
Estas son generalmente más costosas de ejecutar, ya que requieren que más
partes de nuestra aplicación se configuren y se encuentren en funcionamiento.
Este tipo de pruebas lo que busca es encontrar todos esos problemas que surgen
al mezclar las diferentes capas de nuestra aplicación.
 Pruebas No Funcionales
Las pruebas no funcionales validan el comportamiento del sistema, especialmente
la infraestructura. También son consideradas caja negra y pueden ser diseñadas
para todos los niveles. Dentro de las pruebas no funcionales existen diferentes
subtipos:
o Pruebas de carga
Esta prueba busca conocer el comportamiento de la aplicación para los distintos

volúmenes de transacciones que se pueden dar en la aplicación, siempre dentro
de unos márgenes reales. A menudo se utilizan para probar funcionalidades con
alto consumo de recursos o con acciones de escritura sobre la aplicación, pero
también pueden darse en otros ámbitos menos críticos.
o Pruebas de estrés
A diferencia de la prueba de carga, la prueba de estrés intenta provocar un

colapso de la aplicación con altos volúmenes de transacciones. El objetivo es
conocer dónde está el límite de transacciones y validar que la aplicación devuelve
un error controlado.
o Prueba de rendimiento
La prueba de rendimiento se realiza para determinar el rendimiento de un sistema

validando atributos de calidad del sistema como capacidad de respuesta,
velocidad, escalabilidad y estabilidad en diversas condiciones de carga.
Como el lector habrá notado, hay una delgada línea entre pruebas de carga,
estrés y rendimiento. Todas ellas buscan poner al límite la aplicación y a menudo,
una misma prueba puede ser de carga o de estrés según el número de
transacciones que se configuren. La principal diferencia se haya en el objetivo de
la prueba y en las medidas que se toman y exportan al final de la ejecución.
o Pruebas de usabilidad
11
Las pruebas de usabilidad o UX (user experience) buscan ofrecer una experiencia
lo más cómoda, intuitiva y eficiente para el usuario. El objetivo de estas pruebas
es conseguir que nuevos clientes se sientan atraídos por la aplicación y los
actuales se sientan cómodos.
 Pruebas de regresión
Solucionar un error detectado en una prueba suele conllevar añadir o extirpar una
parte del código, y esta modificación puede generar nuevos errores en el módulo o
incluso en otros que parecen no estar relacionados.
Para evitar que esto suceda están las pruebas de regresión. La regresión consiste
en volver a pasar ciertas pruebas sobre un componente que ha sufrido un parche
para detectar posibles nuevos errores. En pruebas de este tipo es especialmente
importante la capacidad de reciclaje o de repetir la prueba sin partir de un conjunto
de datos conocido.
Son pruebas, que a su vez pueden ser funcionales, no funcionales o estructurales
y, también, pueden pertenecer a cualquier nivel.
3.2 Selección del tipo de prueba
En este trabajo se estarán realizando pruebas automatizadas en el backend
unitarias, debido a que es necesario conocer si los datos de los cursos son
insertados correctamente en el back de la API.
Para estos casos este tipo de pruebas es el recomendable debido a que, verifica
el lado del servidor o la base de datos de las aplicaciones o el software. También
si no se realiza correctamente, puede crear problemas importantes como
bloqueos, corrupción de datos, pérdida de datos, etc. Además nos permite poder
probar o depurar una parte del proyecto sin la necesidad de disponer del sistema
completo.
12
4. Diseño del caso de pruebas
Se escogió el caso de uso “Gestionar propuesta de plan de estudio” para realizar
los casos de pruebas.
En la Tabla 1 se documenta la información referida al diseño del caso de prueba
“Insertar cursos”
Tabla 1 - Diseño caso de prueba "Insertar cursos"
Columna Instrucciones
Id C1_00_InsertarCurso
Caso de Prueba Insertar curso
Descripción Verificar que al insertar los datos referidos a los
cursos, la inserción de estos sea correcta.
Condiciones previas Verificar que los parámetros de entrada son correctos
Datos / Acciones de Entrada "id_Curso": "1", "year": 2021, "start_Date": "2021-02-
26", "end_Date": "2021-02-26"
Resultado Esperado Registrar los cursos en la base de datos

Puntos de control -
Condiciones posteriores -
Dependencias con otros casos de -

Prueba
Información para el seguimiento
Resultado Obtenido Se cumplió el registro de los cursos y se guardó
exitosamente en la base de datos
Estado Ejecutado y fallido
Última Fecha de Estado 11/05/2021

13
26", "end_Date": "2021-02-26"

Puntos de control -

Prueba
26", "end_Date": "2021-02-26"
14
Puntos de control -

Prueba
26", "end_Date": "2023-02-26"

Puntos de control -

Prueba
15

Datos / Acciones de Entrada "id_Curso": "5", "year": 2023,"start_Date": "2023-02-
26", "end_Date": "2023-02-26"

Puntos de control -

Prueba

“Insertar profesor”
16
Tabla 6 - Diseño caso de prueba "Insertar profesor"
Id C1_01_InsertarProfesor
Caso de Prueba Insertar profesor
Descripción Verificar que al insertar los datos referidos al profesor,
la inserción de estos sea correcta.
Datos / Acciones de Entrada "id_Profesor": "1", "name": "Juan Perez",
"asignatura": "Estructura de datos"
Resultado Esperado Registrar los datos del profesor en la base de datos
Puntos de control -
Prueba
Resultado Obtenido Se cumplió el registro de los datos de los profesores y
se guardó exitosamente en la base de datos

“Insertar profesor”
Tabla 7 - Diseño caso de prueba "Insertar profesor"
Id C1_02_InsertarProfesor
Caso de Prueba Insertar profesor
Descripción Verificar que al insertar los datos referidos al profesor,
la inserción de estos sea correcta.
Datos / Acciones de Entrada "id_Profesor": "2", "name": "Manuel Gzlez",
17
"asignatura": "Cálculo"
Resultado Esperado Registrar los datos del profesor en la base de datos
Puntos de control -
Prueba
Resultado Obtenido Se cumplió el registro de los datos de los profesores y
se guardó exitosamente en la base de datos
18
Conclusiones
Las pruebas de software son una parte integral del ciclo de vida del desarrollo de
software. Garantiza una experiencia de producto impecable para sus usuarios y
puede reducir los costos a largo plazo y hacer que todo el proceso sea más
eficiente. Aunque es posible que algunas empresas o líderes no lo vean
importante ni necesario realizar una inversión en este proceso, como
desarrolladores es crucial saber de la importancia de probar una aplicación de pies
a cabeza.
Después del estudio realizado se concluye que:
 Las pruebas de software son un conjunto de técnicas que nos permiten
asegurar la calidad del producto que estamos desarrollando en sus diferentes
etapas del ciclo de vida.
 Aunque tienen un coste de desarrollo y mantenimiento extra, son
especialmente útiles para facilitar la calidad del software a medio y largo plazo.
 El tipo y cantidad de pruebas tiene que ser acorde al producto que estamos
desarrollando: no es lo mismo un producto grande que una aplicación web para
anotar tareas.
 Todo software debería tener algún tipo de prueba para asegurar su calidad
independientemente del tamaño del mismo o del número de personas
involucradas en su desarrollo.
Con este trabajo se llegó a la conclusión de que la herramienta Postman:
 Permite la colaboración entre miembros del equipo.
 Tiene una interfaz más intuitiva y atractiva.
 Posee extensión para Google Chrome, por lo tanto, no es necesario instalar la
aplicación de escritorio.
 Tiene una opción muy interesante, que son las colecciones, que funciona
básicamente como una base de datos de peticiones.
 Es extensible y se puede integrar con otras herramientas, por ejemplo,
ejecutando las suites de prueba desde un motor de CI/CD.
 Permite agregar scripts en lenguaje JavaScript para agregar validaciones,
configurar y/o automatizar pruebas (esto se realiza directamente en la
petición).
Además, se concluyó que con las pruebas realizadas se logró comprobar el
correcto funcionamiento de la inserción de los datos en la base de datos,
comprendiendo así la importancia de la realización de pruebas de software en los
proyectos.
19
Referencias Bibliográficas
1. Foundation, I. Manual - ISTQB Foundation – SSTQB 2015.
2. Kaner, C. Definición de testing CEM Kaner – KANER. 2015 [cited 2020; Available from:
http://www.kaner.com/pdfs/KanerSocialScienceSTEP.pdf.
3. Patton., R., Software Testing ed. S. Publishing. Vol. 2. 2005: Sams Publishing.
4. Pressman., R.S., Ingeniería del Software: Un enfoque practico. Vol. 6. 2005: Mc Graw Hill
2005.
5. Myers., l.J., “The art of software testing”. Vol. 2. 2004: John Wiley & Sons
6. Kshirasagar Naik and P. Tripathy, “Software testing and quality assurance: Theory and
practice”. Vol. 1. 2008: John Wiley & Sons.
7. Vinay., P.F., “Manage software testing”. Vol. 1. 2008: Auerbach Publications
8. CUERVO, V. ¿Qué es Postman? 2019 [cited 2021; Available from:
https://www.arquitectoit.com/postman/que-es-postman/.
9. Tello, C.I. Postman: colecciones, peticiones y entornos. 2020 [cited 2021; Available from:
https://www.cesarcodecrafter.com/postman-colecciones-peticiones-entornos/.
10. Postman. Automated Testing with Postman. [cited 2021; Available from:
https://www.postman.com.
11. Izquierdo, C. Cómo se hace: API testing con Postman. 2018; Available from:
https://medium.com/@cesiztel/c%C3%B3mo-se-hace-api-testing-con-postman-
978a521552f4.
12. Toledo, F., API testing con Postman y SoapUI, in Federico Toledo. 2020.
13. Morales, V.M.S. Tipos de pruebas y dónde aplicarlas. 2020 [cited 2021; Available from:
https://www.pragma.com.co/academia/lecciones/tipos-de-pruebas-y-donde-aplicarlas.
14. mas, P.y., Los diferentes tipos de testing en el desarrollo de software. 2017, Programacion
y mas.
20

Seminario Final Calidad Equipo #5

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

Seminario Final Calidad Equipo #5

Cargado por

Copyright:

Formatos disponibles

Universidad Tecnológica de La Habana “José

Seminario Final Calidad

Equipo #5: Pruebas de software: Herramienta Postman

Tabla 1 - Diseño caso de prueba "Insertar cursos"..................................................................13

Ilustración 1 - Diagrama de caso de uso del sistema 3

Ilustración 1 - Diagrama de caso de uso del sistema

Como se puede observar en la ilustración 2, en Postman se trabaja con

Esta prueba busca conocer el comportamiento de la aplicación para los distintos

A diferencia de la prueba de carga, la prueba de estrés intenta provocar un

La prueba de rendimiento se realiza para determinar el rendimiento de un sistema

Resultado Esperado Registrar los cursos en la base de datos

Dependencias con otros casos de -

En la Tabla 2 se documenta la información referida al diseño del caso de prueba

Resultado Esperado Registrar los cursos en la base de datos

Dependencias con otros casos de -

Resultado Esperado Registrar los cursos en la base de datos

Dependencias con otros casos de -

Resultado Esperado Registrar los cursos en la base de datos

Dependencias con otros casos de -

En la Tabla 5 se documenta la información referida al diseño del caso de prueba

Resultado Esperado Registrar los cursos en la base de datos

Dependencias con otros casos de -

En la Tabla 6 se documenta la información referida al diseño del caso de prueba

En la Tabla 7 se documenta la información referida al diseño del caso de prueba

También podría gustarte