República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Universitaria

Universidad Politécnica Territorial del Estado Portuguesa “Juan de Jesús
Montilla”
Programa Nacional de Formación en Informática
Guanare, Estado Portuguesa

UNIDAD VII: TECNICAS DE PRUEBAS

 TECNICAS DE PRUEBAS

NIVELES DE PRUEBAS

Los niveles de prueba de software. Cuando se le van a aplicar pruebas a un

software, se tienen en cuenta una serie de objetivos en diferentes escenarios y
niveles de trabajo, debido a que las pruebas son agrupadas por niveles que se
encuentran en distintas etapas del proceso de desarrollo.

 Prueba de unidad

La prueba de unidad es la primera fase de las pruebas dinámicas y se

realizan sobre cada módulo del software de manera independiente. El objetivo
es comprobar que el módulo, entendido como una unidad funcional, está
correctamente codificado.

Se enfocan en un programa o un componente que desempeña una función

específica que puede ser probada y que se asegura que funcione tal y como lo
define la especificación del programa. Los programadores siempre prueban el
código durante el desarrollo, por lo que las pruebas unitarias son realizadas
solamente después de que el programador considera que el componente está
libre de errores. Consiste en una prueba estructural enfocada a los elementos
más pequeños del software. Esta prueba es aplicable a componentes
representados en el modelo de implementación, para verificar que los flujos de
control y de datos estén cubiertos y que ellos funcionen como se espera.

Durante la prueba de unidad, la comprobación selectiva de los caminos de

ejecución es una tarea esencial. Se deben diseñar casos de prueba para
detectar errores debidos a cálculos incorrectos, comparaciones incorrectas o
flujos de control inapropiados. Las pruebas del camino básico y de bucles son
técnicas muy efectivas para descubrir una gran cantidad de errores en los
caminos.

 Prueba de integración

Su objetivo es identificar errores introducidos por la combinación de

programas o componentes probados unitariamente, para asegurar que la
comunicación, enlaces y los datos compartidos ocurran apropiadamente. Se
diseñan para descubrir errores o completitud en las especificaciones de las
interfaces.

En este nivel se asegura que las interfaces y ligas entre las partes del
sistema trabajen apropiadamente. Antes de las pruebas de integración, los
componentes tuvieron que haber pasado sus pruebas individuales, por lo que
el enfoque ahora es sobre el flujo de control entre los módulos, y sobre los
datos que son intercambiados entre ellos de manera independiente.

 Prueba de sistema

Esta prueba tiene como objetivo verificar que se han integrado

adecuadamente todos los elementos del sistema y que realizan las
operaciones apropiadas funcionando como un todo. Es similar a la prueba de
integración, pero con un alcance mucho más amplio.

Es en esta prueba donde se buscan los defectos globales dados por la mala
integración de los módulos y que impiden una buena aceptación en la decisión
del cliente. La responsabilidad es de todos los creadores de cada uno de los
elementos del sistema.
TIPOS DE PRUEBAS

 Prueba de caja blanca

Las pruebas de caja blanca (también llamadas estructurales o de caja

transparente) describen pruebas o métodos en los que se conocen los detalles
y el funcionamiento interno del software que se está probando. Dado que
conoce las funciones, los métodos, las clases, cómo funcionan y cómo se
unen, generalmente está mejor equipado para examinar la integridad lógica del
código.

Por ejemplo, es posible que sepa que hay una peculiaridad en la forma en
que un determinado idioma maneja ciertas operaciones. Podría escribir
pruebas específicas para eso, que de otro modo no sabría escribir en un
escenario de caja negra. Las pruebas unitarias y las pruebas de integración
suelen ser una caja blanca.

 Prueba de caja negra

Por el contrario, las pruebas de caja negra (también llamadas funcionales,

de comportamiento o de caja cerrada) describen cualquier prueba o método en
el que se desconocen los detalles y el funcionamiento interno del software que
se está probando. Dado que no conoce ninguno de los detalles, realmente no
puede crear casos de prueba que se dirijan a escenarios de nicho específicos o
que hagan hincapié en la lógica específica del sistema.

Lo único que sabe es que, para una solicitud o una entrada determinada, se
espera un determinado comportamiento o salida. Por lo tanto, las pruebas de
caja negra prueban principalmente el comportamiento de un sistema. Las
pruebas de un extremo a otro suelen ser una caja negra.

 Pruebas funcionales

Las pruebas funcionales se llevan a cabo para comprobar las

características críticas para el negocio, la funcionalidad y la usabilidad. Las
pruebas funcionales garantizan que las características y funcionalidades del
software se comportan según lo esperado sin ningún problema. Valida
principalmente toda la aplicación con respecto a las especificaciones
mencionadas en el documento Software Requirement Specification (SRS). Los
tipos de pruebas funcionales incluyen pruebas unitarias, pruebas de interfaz,
pruebas de regresión, además de muchas.

 Pruebas no funcionales

Las pruebas no funcionales son como pruebas funcionales; sin embargo, la

principal diferencia es que esas funciones se prueban bajo carga para el
rendimiento de los observadores, fiabilidad, usabilidad, escalabilidad, etc. Las
pruebas no funcionales, como las pruebas de carga y esfuerzo, normalmente
se llevan a cabo mediante herramientas y soluciones de automatización, como
LoadView. Además de las pruebas de rendimiento, los tipos de pruebas no
funcionales incluyen pruebas de instalación, pruebas de confiabilidad y pruebas
de seguridad.

 Pruebas visuales / de interfaz de usuario

Las pruebas de la interfaz de usuario o del navegador describen pruebas

que examinan específicamente la integridad y el comportamiento de los
componentes de la interfaz de usuario. A menudo, cuando se utiliza un sitio
web, se espera que determinadas acciones den lugar a determinados estados.
Las pruebas de IU verifican que esto ocurra correctamente. Por ejemplo, la
forma en que ha implementado cierto CSS puede fallar en Firefox, pero no en
Chrome. Las pruebas del navegador pueden comprobarlo.

 Pruebas de aceptación

Las pruebas de aceptación son definidas por el usuario del sistema y

preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final
corresponden al usuario. Estas pruebas van dirigidas a comprobar que el
sistema cumple los requisitos de funcionamiento esperado, recogidos en el
catálogo de requisitos y en los criterios de aceptación del sistema de
información, y conseguir así́ la aceptación final del sistema por parte del
usuario. El responsable de usuarios debe revisar los criterios de aceptación
que se especificaron previamente en el plan de pruebas del sistema y,
posteriormente, dirigir las pruebas de aceptación final.

La validación del sistema se consigue mediante la realización de

pruebas de caja negra que demuestran la conformidad con los requisitos y que
se recogen en el plan de pruebas, el cual define las verificaciones a realizar y
los casos de prueba asociados. Dicho plan está diseñado para asegurar que se
satisfacen todos los requisitos funcionales especificados por el usuario
teniendo en cuenta también los requisitos no funcionales relacionados con el
rendimiento, seguridad de acceso al sistema, a los datos y procesos, así́ como
a los distintos recursos del sistema. La formalidad de estas pruebas dependerá́
en mayor o menor medida de cada organización, y vendrá́ dada por la criticidad
del sistema, el número de usuarios implicados en las mismas y el tiempo del
que se disponga para llevarlas cabo, entre otros.
I DETECCION Y CORRECCION DE ERRORES DEL PROYECTO

Planificación de Pruebas del Software (Unidad, Integración, y Sistemas)

El plan de pruebas se llevará a cabo bajo el método de caja blanca y

funcional y tiene como objetivo la detección y solución de errores, fallas o
defectos que podría presentar el software.

Objetivo General: Detectar y solucionar errores, fallas o defectos que pueda

presentar la aplicación web.
Objetivos Actividades Lugar / Fecha Responsables
Específicos
-Validar que la entrada  Correa G.
de datos y el orden del Dennys A.
código sea la correcta Ambiente de
Desarrollo  Durand C.
en todos los módulos.
José D.
Unidad -Verificar las funciones 17/10/2021
matemáticas de una
venta y compra

-Validar la existencia
del objeto
-Evaluar el control de  Correa G.
las consultas, Dennys A.
vacunaciones, Ambiente de
Integración Desarrollo  Durand C.
desparasitaciones y
jornada de José D.
vacunaciones 17/10/2021

-Evaluar el control de
las ventas y compras

-Verificar las interfaces

de usuario
-Verificar el correcto  Leo M.
funcionamiento de Ambiente de Inés S.
todos los reportes Desarrollo
Sistema generales y dinámicos
17/10/2021
-Evaluar el correcto
funcionamiento de
todos los módulos y
sus formularios
Observaciones:
Diseño de Casos de Pruebas

El software “Sistema De Gestión De Veterinaria (SISVET)” fue

desarrollado utilizando Python (Django: Framework para el desarrollo web de
código abierto). Se utilizó “PostgreSQL” como manejador de base de datos y
librerías de JavaScript para la comodidad del usuario, Estas herramientas
hicieron posible el correcto funcionamiento de la aplicación web.

Las pruebas de unidad fueron realizadas utilizando la metodología de

caja blanca y prueba funcional, en esta utilizamos una herramienta que ofrece
Django para la realización de pruebas, aplicando condiciones o caminos en
cada una de las pruebas, entre ellas está la comprobación de id de cada uno
de los objetos y la validación de los datos que se registran, otras de las
pruebas fue el correcto funcionamiento de las operaciones matemáticas que se
realizan en el software.

Las pruebas de integración fueron realizadas bajo la misma metodología

y utilizada con la misma herramienta, unas de las pruebas fueron la de evaluar
el control de consultas, desparasitaciones y vacunaciones para comprobar
cómo trabajan conjuntamente entre las mascotas y sus respectivos clientes. De
igual manera se trabajó con el control de ventas para evaluar cómo se
relacionan los almacenes, categorías y sus respectivos productos. Y por último
la verificación de las interfaces según el nivel de usuario.

Las pruebas de sistema fueron realizadas utilizando la metodología

funcional en el cual allí se evalúan los requerimientos funcionales del sistema
entre las cuales están el correcto funcionamiento de todos los módulos y los
reportes.

Resultado de Pruebas del Software (Unidad, Integración, Y Sistemas).

 Los resultados de las pruebas realizadas para la aplicación web fueron
satisfactorios, tanto en las pruebas de unidad, integración y sistema.

Objetivo General: Solucionar posibles errores detectados en las pruebas de

unidad, integración y sistema en la aplicación web.
Objetivos RESULTADOS
Lugar / Fecha Responsables
Específicos OBTENIDOS
-Las validaciones en los  Correa G.
campos claves y en los Dennys A.
datos funcionan de forma Ambiente de  Durand C.
correcta. Desarrollo
José D.
-Las Operaciones 18/06/2020
Unidad
matemáticas que se
realizan en el software se
ejecutan de manera
esperada.

-Todos los módulos se  Correa G.

integran perfectamente a Dennys A.
la aplicación. Ambiente de
Integración Desarrollo  Durand C.
-La interfaz funciona de José D.
una manera correcta 18/06/20
para el usuario.

-La aplicación cumple  Leo M.

con todos los Ambiente de Inés S.
requerimientos tanto Desarrollo
Sistema funcionales como no
funcionales. 18/06/2020

Observaciones: