Tipos de Pruebas de Software

“Año del Bicentenario del Perú: 200 años de Independencia”
UNIVERSIDAD NACIONAL “SAN LUIS GONZAGA” DE ICA
FACULTAD DE INGENIERÍA DE SISTEMAS
ASIGNATURA:
CONTROL DE CALIDAD Y PRUEBAS DE SOFTWARE
TRABAJO:
TIPOS DE PRUEBA DE SOFTWARE
INTEGRANTES:
CASTILLA DAGNINO, RENZO ISRAEL
CASTRO HERNÁNDEZ, LUIS GERMAN
FLORES CCECCAÑO, CRISTHIAN EDGAR
PEDRAZA RIOS, SHIARIR
TATAJE DE LA CRUZ, JEISSON HAMETT
DOCENTE:
ROMERO LOVERA, JHON ALEX
CICLO Y SECCIÓN:
VIII – “A”
ICA – PERÚ
2021
________________________________________________________________________________________________________
ÍNDICE DE CONTENIDOS
ÍNDICE DE CONTENIDOS ................................................................................................... 2

I. TIPOS DE PRUEBAS ......................................................................................................... 3
1. TIPOS DE PRUEBAS SEGÚN SUS FORMAS ............................................................... 3
1.1 PRUEBAS MANUALES ................................................................................. 3
1.2 PRUEBAS AUTOMATIZADAS ..................................................................... 4
2. TIPOS DE PRUEBAS SEGÚN SUS MÉTODOS ............................................................ 4
2.1 PRUEBAS DE CAJA BLANCA ...................................................................... 4
2.2 PRUEBAS DE CAJA NEGRA ........................................................................ 5
2.3 PRUEBAS DE CAJA GRIS ............................................................................ 6
3. TIPOS DE PRUEBAS SEGÚN SUS NIVELES ............................................................... 7
3.1 PRUEBAS NO FUNCIONALES ..................................................................... 7
3.1.1 PRUEBAS DE CARGA .............................................................................................. 7
3.1.2 PRUEBAS DE RENDIMIENTO................................................................................ 8
3.1.3 PRUEBAS DE VOLUMEN ........................................................................................ 8
3.1.4 PRUEBAS DE ESTRÉS .............................................................................................. 9
3.1.5 PRUEBAS DE SEGURIDAD ..................................................................................... 9
3.1.6 PRUEBAS DE USABILIDAD .................................................................................... 9
3.2 PRUEBAS FUNCIONALES ........................................................................... 9
3.2.1 PRUEBAS UNITARIAS ............................................................................................. 9
3.2.2 PRUEBAS DE COMPONENTES ............................................................................ 10
3.2.3 PRUEBAS DE HUMO .............................................................................................. 11
3.2.4 PRUEBAS DE INTEGRACIÓN .............................................................................. 11
3.2.5 PRUEBAS DE REGRESIÓN ................................................................................... 12
3.2.6 PRUEBAS DE ACEPTACIÓN ................................................................................ 13
CONCLUSIONES .................................................................................................................. 14
REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 15
ANEXOS ................................................................................................................................. 16
2
________________________________________________________________________________________________________
I. TIPOS DE PRUEBAS
1. TIPOS DE PRUEBAS SEGÚN SUS FORMAS
1.1 PRUEBAS MANUALES
La prueba manual es un tipo prueba de software involucrar a los probadores
manualmente casos de prueba ejecutar sin usar herramientas de automatización. Los
comprobadores están realmente detrás de la pantalla de la aplicación, llevan a cabo
casos de prueba y ven cuál es el resultado. (Hoogenraad, 2017)
OBJETIVO DE LAS PRUEBAS MANUALES
El concepto principal de las pruebas manuales es garantizar que la aplicación
esté libre de errores. También determinamos que está de acuerdo con los requisitos
funcionales y los criterios de aceptación especificados.
El acompañante plan de prueba, los casos de prueba y los casos de prueba
deben cubrir el software al 100%. Los diseñamos al mismo tiempo que construimos el
software o durante la fase de prueba. Esto asegura que los desarrolladores puedan
corregir las fallas reportadas por los probadores. Luego, los probadores ejecutan la
prueba nuevamente para verificar que el error se haya corregido. Sin embargo,
nuevamente podemos encontrar otros errores. Este proceso continúa hasta que la
aplicación esté libre de errores. En principio, verificamos la calidad de la aplicación
mediante pruebas. Con el objetivo de entregar un producto sin errores al usuario.
• La repetición de pruebas manuales podría dejar pasar defectos, ya que una
acción repetitiva para una persona es cansada y tediosa.
3
________________________________________________________________________________________________________
• Las pruebas de regresión manuales pueden llegar a consumir mayor
tiempo que las automatizadas. Es necesario incluir pruebas de regresión cuando
se está haciendo una actualización o ampliación de la funcionalidad del sistema.
• Las pruebas manuales son indispensables para cada proyecto, ya que por medio
de ellas se detectan la mayor parte de los defectos, y de esta forma se logra
estabilizar el sistema que se está probando.
• Las pruebas manuales permiten un análisis profundo por parte de un humano, lo
cual es un mayor beneficio cuando se quiere mejorar la experiencia de usuario.
(INTERWARE, 2018)
1.2 PRUEBAS AUTOMATIZADAS
• Las pruebas automatizadas pueden brindar un mayor grado de confiabilidad
cuando se aplican después de algún cambio al hardware o software donde se
ejecuta el sistema.
• Las pruebas automatizadas son la opción más viable cuando se necesita realizar
diversas pruebas, de manera repetitivas y por un período de tiempo extenso.
• Las pruebas automatizadas pueden ejecutarse una y otra vez luego de ser
creadas, más rápido que las pruebas manuales, idóneas para ampliaciones de
funciones, para garantizar que lo que no se ha modificado siga funcionando.
2. TIPOS DE PRUEBAS SEGÚN SUS MÉTODOS
2.1 PRUEBAS DE CAJA BLANCA
La prueba de caja blanca se basa en el diseño de casos de prueba que usa la
estructura de control del diseño procedimental para derivarlos. Mediante la prueba de
la caja blanca el ingeniero del software puede obtener casos de prueba que:
4
________________________________________________________________________________________________________
a) Garanticen que se ejerciten por lo menos una vez todos los caminos
independientes de cada módulo, programa o método.
b) Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
c) Ejecuten todos los bucles en sus límites operacionales.
d) Ejerciten las estructuras internas de datos para asegurar su validez.
Es por ello por lo que se considera a la prueba de caja blanca como uno de los
tipos de pruebas más importantes que se les aplican a los softwares, logrando como
resultado que disminuya en un gran porciento el número de errores existentes en los
sistemas y por ende una mayor calidad y confiabilidad. (Pressman, 1982)
2.2 PRUEBAS DE CAJA NEGRA
Las pruebas de caja negra son, ni más ni menos que, pruebas funcionales
dedicadas a “mirar” en el exterior de lo que se prueba. Estas pruebas se denominan de
varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas
por datos…los sinónimos son muchos y muy variados.
¿CÓMO SE REALIZAN LAS PRUEBAS DE CAJA NEGRA?
Cada empresa o tester, tienen su estrategia a la hora de aplicar este tipo de
prueba, dependiendo del tipo de aplicación o el tiempo asignado a pruebas, entre otros
factores, se realizan las pruebas de caja negra de una forma más intensiva o más
exploratorias. Aun así, hay una secuencia de pasos a seguir media estandarizada para
poder realizar este tipo de prueba de manera efectiva:
• Lo primero será un previo análisis de los requisitos y especificaciones del
software.
• El tester diseñará una batería de entradas validas, también llamado escenario de
prueba positiva, para verificar si el software las procesa correctamente. También
5
________________________________________________________________________________________________________
se diseñan entradas no válidas (llamado escenario de prueba negativa)
para comprobar si el software que se está probando es capaz de detectarlas y
reaccionar antes estas entradas.
• Basándose en las entradas, el tester determina para cada una de estas las salidas
esperadas correspondientes.
• Una vez que se tienen las entradas y su correspondiente salida, se diseña los
casos de prueba.
• Se ejecutan esos casos de pruebas.
• El tester comprueba la salida que ha emitido el software con la salida esperada
de los casos de prueba.
• Si la salida del software coincide con la salida esperada, el software hace lo que
tiene que hacer para esa entrada. Pero si la salida del software no coincide con la
salida esperada, hemos encontrado un defecto en el software. Lo que conllevará
su posterior reparación. (HOW TO TESTING, 2019)
2.3 PRUEBAS DE CAJA GRIS
Es una técnica de prueba de software para probar un producto o aplicación de
software con un conocimiento parcial de la estructura interna de la aplicación. El
propósito de la prueba de caja gris es buscar e identificar fallas debido a una estructura
de código incorrecta o al uso de la aplicación.
En este proceso, los errores específicos del contexto asociados con los sistemas
web se identifican comúnmente. Aumenta la cobertura de la prueba al centrarse en
todas las capas de cualquier sistema complejo.
Las técnicas utilizadas para las pruebas de caja gris son:
6
________________________________________________________________________________________________________
• Prueba de matriz: Esta técnica de prueba implica definir todas las
variables en sus programas.
• Pruebas de regresión: Compruebe si el cambio a la versión anterior ha recuperado
otras características del programa en la nueva versión. Se hará probando estrategias
como reexaminar cada una, reexaminar los casos de uso de riesgo, reexaminar
dentro de un firewall.
• Prueba de matriz ortogonal o OAT: Proporciona la máxima cobertura de código
con instancias de prueba mínimas.
• Prueba de patrón: Esta prueba se realiza con datos históricos de fallas anteriores
del sistema. A diferencia de una prueba de caja negra, una prueba de caja gris se
excava dentro del código y determina por qué ocurrió la falla. (EBOOKS, 2015)
3. TIPOS DE PRUEBAS SEGÚN SUS NIVELES
3.1 PRUEBAS NO FUNCIONALES
Las pruebas no funcionales son aquellas que verifican requisitos basados en la
operación de un software, no en la funcionalidad en sí. Este tipo de pruebas, pueden
ayudarnos a determinar la carga que soporta el producto, si su rendimiento es el
correcto o si está estable a nivel de contacto con el servidor.
3.1.1 PRUEBAS DE CARGA
Las pruebas de carga consisten en simular una serie de accesos sobre un
software y medir el resultado. Estas pruebas se realizan bajo demanda esperada
y también en condiciones de sobrecarga.
Estas ayudan a identificar la máxima capacidad operativa de un
software, identificando cuellos de botella y las causas de posible degradación
del desempeño o servicio.
7
________________________________________________________________________________________________________
3.1.2 PRUEBAS DE RENDIMIENTO
Es una técnica de prueba de software no funcional que determina cómo
la estabilidad, la velocidad, la escalabilidad y la capacidad de respuesta de una
aplicación se mantiene bajo una determinada carga de trabajo. Es un paso clave
para asegurar la calidad del software, pero desafortunadamente, a menudo se
ve como una reflexión posterior, en aislamiento, y para comenzar una vez que
se completan las pruebas funcionales, y en la mayoría de los casos, después de
que el código está listo para ser distribuido.
Los objetivos de las pruebas de rendimiento incluyen la evaluación de
la salida de la aplicación, la velocidad de procesamiento, la velocidad de
transferencia de datos, el uso del ancho de banda de la red, el máximo de
usuarios concurrentes, la utilización de la memoria, la eficiencia de la carga de
trabajo y los tiempos de respuesta de los comandos.
3.1.3 PRUEBAS DE VOLUMEN
Comprueban que el funcionamiento de la aplicación con ciertos
volúmenes de datos es adecuado. Estas pruebas no están limitadas a bases de
datos, también se pueden usar, por ejemplo, para medir el desempeño de una
interfaz en el supuesto de que un archivo supera un tamaño estipulado.
El objetivo es ver si dado ciertos volúmenes de datos la aplicación
funciona con normalidad, cuáles son los límites máximos de volúmenes de
datos para la operación e identificar condiciones de falla.
8
________________________________________________________________________________________________________
3.1.4 PRUEBAS DE ESTRÉS
Están relacionadas con las pruebas de carga, ya que, si se eleva por
encima de los parámetros esperados, a estas pruebas se les conoce como
pruebas de estrés. Con las pruebas de estrés se pueden identificar los puntos de
ruptura, límites para uso seguro de la aplicación, confirmar las especificaciones
de diseño, identificar las formas en que el sistema falla, entre otras muchas
validaciones.
3.1.5 PRUEBAS DE SEGURIDAD
Relacionadas con el hacking ético, detectar vulnerabilidades y auditoria
de buenas prácticas, comprueban los atributos o características de seguridad del
sistema, si es un sistema seguro o no, si puede ser vulnerado, si existe control
de acceso por medio de cuentas de usuario, si pueden ser vulnerados estos
accesos.
3.1.6 PRUEBAS DE USABILIDAD
Son aquellas que validan cuanto es de fácil el usar el software de cara a
los usuarios finales, de esta manera consideramos un software adecuado y que,
posiblemente, se posicione por encima de sus competidores principales.
(QALovers, 2021)
3.2 PRUEBAS FUNCIONALES
Las pruebas funcionales son una práctica beneficiosa cuando nos referimos al
proceso del desarrollo. De esta manera puedes tener el progreso del proyecto para la
administración en las pruebas funcionales aprobadas y reprobadas. Aquí se facilita la
comunicación entre desarrolladores, analistas y evaluadores.
3.2.1 PRUEBAS UNITARIAS
9
________________________________________________________________________________________________________
Las pruebas unitarias son las que aseguran que cada célula del
código desarrollado en un componente brinde los resultados adecuados. En
estas pruebas los desarrolladores observan la interfaz y la especificación de un
componente, proporcionando la documentación del desarrollo del código se
prueba exhaustivamente, claro que de forma independiente antes de pasar a
otra unidad.
Las pruebas unitarias admiten pruebas funcionales al ejercer el código que es
más probable que se rompa. Por ello, si usas pruebas funcionales sin pruebas
unitarias, puedes experimentar algunas dificultades para diagnosticar pruebas
fallidas. Así que tenlas muy presente.
3.2.2 PRUEBAS DE COMPONENTES
Las pruebas de componentes se ejecutan de forma independiente para
comprobar que el resultado sea el requerido. Su objetivo es verificar las
funcionalidades y/o usabilidades de los componentes, aunque no solo se limite
a eso.
Para ilustrarla mejor, un ejemplo de esta prueba puede ser cualquier
elemento que tenga entrada y deba generar alguna salida. Puede ser el módulo
de código, página web, pantallas e incluso un sistema dentro de un sistema más
grande, en un componente. Aquí algunos usos de los componentes que puedes
probar:
• Prueba de UI para usabilidad y accesibilidad
• Prueba de carga para asegurar el rendimiento
10
________________________________________________________________________________________________________
• Inyección de SQL a través de componentes de UI para
asegurar la seguridad
• Prueba de login con credenciales válidas e inválidas
3.2.3 PRUEBAS DE HUMO
Las pruebas 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 funcionales más importantes y debería 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 realizará 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.
3.2.4 PRUEBAS DE INTEGRACIÓN
La prueba de integración es uno de los tipos de prueba funcional más
común y se realiza de forma automatizada. Se realizan para probar
11
________________________________________________________________________________________________________
componentes individuales con el objetivo de verificar cómo los
módulos, que trabajan de forma individual, funcionan cuando estén integrados.
El objetivo de realizar estas 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 bases datos, entre
otras.
Algunas de las verificaciones que se realizan en las pruebas de integración son:
• Prueba de interfaz: en la comprobación de las transferencias de datos
entre dos 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.
3.2.5 PRUEBAS DE REGRESIÓN
Es normal que los desarrolladores modifiquen y mejoren las
funcionalidades de su desarrollo. Por ello existe una gran posibilidad de que
puedan causar ‘efectos’ inesperados en su comportamiento. Estas pruebas de
12
________________________________________________________________________________________________________
regresión se realizan para asegurar que los cambios o adiciones no
hayan alterado ni eliminado las funcionalidades existentes.
El objetivo de las pruebas de regresión es encontrar errores que puedan
haber sido introducidos accidentalmente en la compilación existente y así
garantizar que los errores eliminados continúen así.
3.2.6 PRUEBAS DE ACEPTACIÓN
Cuando ya hemos seguido e implementado las pruebas que requerimos
para nuestro producto, hacemos las pruebas de aceptación. Estas hacen parte
de la última fase de este proceso de testing. Aquí los usuarios reales del
software lo usan para verificar que cumpla con las tareas requeridas en un
ambiente ‘real’. En ocasiones se realiza cuando se hace la entrega del producto
“como punto de control final entre todos los tipos de pruebas funcionales”.
Desde el inicio hasta la implementación, el software deberá someterse a
varios tipos de pruebas. El objetivo siempre será asegurar la calidad para evitar
reprocesos y garantizar las funcionalidades de la aplicación, tanto para el
usuario final, como para el cliente.
Sin más, recuerda que estas son las pruebas de aseguramiento de
calidad más importantes que puedes implementar para entregar desarrollos
productos y/o aplicaciones de otro nivel. Así podrás cumplir con los
requerimientos del cliente y entregar soluciones funcionales y de calidad.
(Vargas, 2021)
13
________________________________________________________________________________________________________
CONCLUSIONES
La comprensión de la importancia de cada prueba de software, para poder encaminarnos al
requerimiento del cliente, a los objetivos de la empresa, ya que gracias a esto el equipo de
desarrollo podrá corregir con distintas pruebas los errores y bugs y se podrá entregar un
producto de buena calidad.
Podemos catalogarlo como como una de las actividades más importantes y fundamentales en el
desarrollo de nuestro proyecto, ya que al emplearlo va a aperturar una serie de posibilidades en
procesos, métodos de trabajo y herramientas necesarias para poder garantizar la calidad del
proyecto.
Existen casos donde las empresas ven estos tipos de pruebas como pérdida de dinero y no como
una inversión a largo plazo, ya que de inmediato con estos maravillosos instrumentos podremos
detectar anomalías o errores que en el futuro nos pueda complicar y generar gastos extras de
dinero, por ende visualizamos la inversión en el testing de software como el aseguramiento de
calidad.
14
________________________________________________________________________________________________________
REFERENCIAS BIBLIOGRÁFICAS
EBOOKS. (2015). Prueba de Caja gris. ¿Qué Es Una Prueba de Caja Gris? Técnicas,
Ejemplo. https://ebooksonline.es/que-es-una-prueba-de-caja-gris-tecnicas-ejemplo/
Hoogenraad, W. (2017). ¿Qué es una prueba manual? ITpedia.
https://es.itpedia.nl/2017/10/11/wat-is-handmatig-testen/
HOW TO TESTING. (2019). Pruebas de Caja Negra. Pruebas de Caja Negra.
https://howtotesting.com/testing-funcional/pruebas-de-caja-negra/
INTERWARE. (2018). Pruebas manuales vs pruebas automatizadas. Software Testing.
https://www.interware.com.mx/blog/pruebas-manuales-vs-pruebas-automatizadas
Pressman, R. S. (1982). Ingeniería del software; Un enfoque práctico.
https://www.ecured.cu/Pruebas_de_caja_blanca#cite_ref-1
QALovers. (2021). Introducción al Testing: Pruebas no funcionales. Introducción Al Testing.
https://www.qalovers.com/2019/01/pruebas-no-funcionales.html
Vargas, C. (20021). Tipos de pruebas funcionales para el aseguramiento de la calidad. Tipos
de Pruebas Funcionales. https://trycore.co/transformacion-digital/tipos-de-pruebas-
funcionales/
15
________________________________________________________________________________________________________
ANEXOS
16
________________________________________________________________________________________________________
17
________________________________________________________________________________________________________
18

Tipos de Pruebas de Software

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

Tipos de Pruebas de Software

Cargado por

Copyright:

Formatos disponibles

“Año del Bicentenario del Perú: 200 años de Independencia”

UNIVERSIDAD NACIONAL “SAN LUIS GONZAGA” DE ICA

FACULTAD DE INGENIERÍA DE SISTEMAS

ÍNDICE DE CONTENIDOS ................................................................................................... 2

1. TIPOS DE PRUEBAS SEGÚN SUS FORMAS

1.1 PRUEBAS MANUALES

La prueba manual es un tipo prueba de software involucrar a los probadores

manualmente casos de prueba ejecutar sin usar herramientas de automatización. Los

comprobadores están realmente detrás de la pantalla de la aplicación, llevan a cabo

casos de prueba y ven cuál es el resultado. (Hoogenraad, 2017)

OBJETIVO DE LAS PRUEBAS MANUALES

El concepto principal de las pruebas manuales es garantizar que la aplicación

funcionales y los criterios de aceptación especificados.

El acompañante plan de prueba, los casos de prueba y los casos de prueba

aplicación esté libre de errores. En principio, verificamos la calidad de la aplicación

mediante pruebas. Con el objetivo de entregar un producto sin errores al usuario.

• La repetición de pruebas manuales podría dejar pasar defectos, ya que una

acción repetitiva para una persona es cansada y tediosa.

• Las pruebas de regresión manuales pueden llegar a consumir mayor

tiempo que las automatizadas. Es necesario incluir pruebas de regresión cuando

se está haciendo una actualización o ampliación de la funcionalidad del sistema.

de ellas se detectan la mayor parte de los defectos, y de esta forma se logra

estabilizar el sistema que se está probando.

• Las pruebas manuales permiten un análisis profundo por parte de un humano, lo

cual es un mayor beneficio cuando se quiere mejorar la experiencia de usuario.

1.2 PRUEBAS AUTOMATIZADAS

• Las pruebas automatizadas pueden brindar un mayor grado de confiabilidad

cuando se aplican después de algún cambio al hardware o software donde se

diversas pruebas, de manera repetitivas y por un período de tiempo extenso.

funciones, para garantizar que lo que no se ha modificado siga funcionando.

2. TIPOS DE PRUEBAS SEGÚN SUS MÉTODOS

2.1 PRUEBAS DE CAJA BLANCA

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la

estructura de control del diseño procedimental para derivarlos. Mediante la prueba de

independientes de cada módulo, programa o método.

b) Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.

c) Ejecuten todos los bucles en sus límites operacionales.

d) Ejerciten las estructuras internas de datos para asegurar su validez.

resultado que disminuya en un gran porciento el número de errores existentes en los

sistemas y por ende una mayor calidad y confiabilidad. (Pressman, 1982)

2.2 PRUEBAS DE CAJA NEGRA

dedicadas a “mirar” en el exterior de lo que se prueba. Estas pruebas se denominan de

varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas

por datos…los sinónimos son muchos y muy variados.

¿CÓMO SE REALIZAN LAS PRUEBAS DE CAJA NEGRA?

Cada empresa o tester, tienen su estrategia a la hora de aplicar este tipo de

poder realizar este tipo de prueba de manera efectiva:

• Lo primero será un previo análisis de los requisitos y especificaciones del

• El tester diseñará una batería de entradas validas, también llamado escenario de

prueba positiva, para verificar si el software las procesa correctamente. También

se diseñan entradas no válidas (llamado escenario de prueba negativa)

para comprobar si el software que se está probando es capaz de detectarlas y

reaccionar antes estas entradas.

• Se ejecutan esos casos de pruebas.

• El tester comprueba la salida que ha emitido el software con la salida esperada

de los casos de prueba.

salida esperada, hemos encontrado un defecto en el software. Lo que conllevará

su posterior reparación. (HOW TO TESTING, 2019)

2.3 PRUEBAS DE CAJA GRIS

Es una técnica de prueba de software para probar un producto o aplicación de

software con un conocimiento parcial de la estructura interna de la aplicación. El

de código incorrecta o al uso de la aplicación.

web se identifican comúnmente. Aumenta la cobertura de la prueba al centrarse en

todas las capas de cualquier sistema complejo.