Nombre de la materia

Administración de las TI.

Nombre de la Licenciatura
Ingeniería en Sistemas
Computacionales

Nombre del alumno

Luis Manuel Mora López

Matrícula
010577912

Nombre de la Tarea
Ejercicio. Distinción de los diferentes
tipos de pruebas.

Nombre del Profesor

Rodrigo Aryan Hernández García.

Fecha
22/07/2020
 Unidad 2: Pruebas de Software.
Administración de las TI.

Introducción:

Para empezar este trabajo empezaré definiendo qué son las pruebas de software.
Estas pruebas son las investigaciones empíricas y técnicas cuyo objetivo es
proporcionar información objetiva e independiente sobre la calidad del software al
que vamos a testear. En palabras más coloquiales, estas pruebas nos arrojarán
datos al respecto del funcionamiento del software que estemos desarrollando y
también definir las acciones en caso de que se requieran cambios.

En esta actividad definiremos algunos de las pruebas de software a desarrollar en

nuestra vida profesional.

Desarrollo:

Instrucciones:

1. En un documento de Word, elabora una tabla comparativa donde

enlistes los diferentes tipos de pruebas de software, así como las
ventajas y desventajas.
2. Con base en la información de la tabla, deberás realizar un análisis
comparativo y definir en qué situación recomendarías cada una de
ellas.  
3. Selecciona las pruebas de software esenciales, es decir, aquellas que
consideras que deben aplicarse en la mayoría de los desarrollos de
software. 

Prueba Ventajas Desventajas

Pruebas Unitarias. 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 nuestro software.
* Este procedimiento ágil * Es un hecho que en un
nos permite detectar caso simple se pierde
errores a tiempo, de aproximadamente el 20%
forma en que puedas de la implementación real,
reescribir el código o ahora para los casos más
corregir los errores a complejos se requiere
tiempo sin necesidad de invertir mucho más
tener que volver al tiempo.

2
 Unidad 2: Pruebas de Software.
Administración de las TI.

Se debe aislar la principio y rehacer el * Para los casos

funcionalidad hasta un trabajo. complejos, los procesos
punto que no se pueda de prueba son más
* También nos ayudará a
desglosar más y complicados de calcular.
realizar pruebas
entonces será momento continuamente y detectar * Muchas veces el diseño
de escribir las pruebas en los errores cuando el no es muy claro al
base a ello. código está terminado, principio e irá
Verifican que el nombre entregando un código evolucionando a medida
de la función o método limpio y de calidad. que avanza, lo cual nos
sea el adecuado que los obligará a rehacer la
* A diferencia de otros
nombres y tipos de prueba lo cual generará
procesos, estos nos
parámetros sean una gran pérdida de
permiten detectar errores
correctos y así el mismo tiempo.
de forma más rápida ya
valor se devuelve como que se analiza el código * Para las estructuras de
resultado. por partes realizando así datos y los algoritmos de
diferentes pruebas de caja negra, estas pruebas
manera periódica hasta se pueden adaptar
obtener el resultado más perfectamente, pero para
óptimo. los algoritmos que tienden

* Nos permitirán modificar a ser modificados o

ajustados, esto puede
las partes del código sin
causar una gran inversión
afectar al conjunto, esto
de tiempo que realmente
simplemente para
podría no estar justificado.
solucionar los bugs que
puedan aparecer en el
proceso.

* Este procedimiento ágil

nos permite detectar
errores a tiempo, de
forma en que puedas

3
 Unidad 2: Pruebas de Software.
Administración de las TI.
Pruebas de Aceptación.
Esta es la última acción
de prueba de desplegar
el software. Su objetivo
principal es comprobar si
el software está
preparado y lo pueden
utilizar los usuarios para
realizar las funciones y
tareas para las cuales
fueron diseñados.
reescribir el código o
corregir los errores a
tiempo sin necesidad de
tener que volver al
principio y rehacer el
trabajo.
* Ya que los errores se
detectan a tiempo nos
evitaremos el escribir
código de más y así
podremos diseñar a la
vez que se crea y
optimizar los tiempos de
entrega, esto reduce
considerablemente el
costo económico.
*Normalmente las *Se requiere de una
funciones y las planificación y recursos
características que se significativos.
van a probar, nos *Las pruebas pueden ser
sentimos familiarizadas una re implementación de
con ellas. las pruebas del sistema.
*Los detalles de las *Es posible que las
pruebas que se realizarán pruebas no revelen
son aquellas con las que defectos subjetivos en el
ya las conocemos y software ya que sólo
podemos medir. busca defectos que
*También las pruebas espera encontrar.
pueden automatizarse,
por lo cual por lo cual se
4
 Unidad 2: Pruebas de Software.
Administración de las TI.
Pruebas de caja blanca.
Es un método de pruebas
de software que pone a
prueba las estructuras
internas o funcionamiento
de una aplicación en
contraposición a su
funcionalidad.
pueden realizar pruebas
de regresión.
*El progreso de las
pruebas se pueden medir
y también supervisar.
*Los criterios de
aceptabilidad también
son familiares.
*Los efectos secundarios *La complejidad de la
de tener conocimiento del prueba se ve reflejada ya
código fuente resulta una que el tester tiene que
ventaja importante. tener el conocimiento del
programa, además de ser
*La optimización del
un programador de un alto
código se vuelve en fácil
nivel de conocimiento ya
como en cuellos de
que las pruebas lo
botella poco visibles,
requieren así.
ahora quedarían
expuestos. *Se considera que
muchas veces las
*Se da la introspección al
pruebas no son realistas
programador ya que los
desarrolladores describen para probar cada una de
las condiciones existentes
cuidadosamente
en la aplicación y otras
cualquier nueva
tendrán que ser puestas a
aplicación.
prueba.
*Proporcionan
*Las pruebas se centran
trazabilidad de las
en el software, esto puede
pruebas de la fuente, lo
presentar que la
que permite cambios a
funcionalidad faltante no
futuro en las fuentes que
siempre puede ser
5
 Unidad 2: Pruebas de Software.
Administración de las TI.
Prueba de caja negra.
Estas pruebas se llevan a
cabo sobe la interfaz del
software, obviando el
comportamiento interno y
estructura del programa.
Pruebas de regresión.
Estas pruebas son las
encargadas de probar los
recién se hayan añadido descubierta.
modificado *La prueba resultante
recientemente. puede ser frágil ya que
*Su automatización están estrechamente
resulta sencilla. vinculadas a la aplicación
concreta de lo que se está
*Proporciona reglas
probando. Por ejemplo, un
claras, basadas en
ingeniería para cuando se código no tan complejo
puede ser reescrito para
detenga la prueba.
implementar la misma
funcionalidad pero de
diferente forma para evitar
errores de compilación.
*A diferencia de la caja *La primordial desventaja
blanca que se lleva a es que no suele estar en
cabo previamente en el el número de funciones
proceso de prueba, proporcionada por el
tiende a ser aplicada en módulo, sino en los datos
posteriores fases de que pasan estas
prueba. funciones.
*Ya que esta prueba
intencionalmente ignora
la estructura de control,
concentra la mayor parte
de su atención en el
domino de la información.
*Ayudan a minimizar *El costo no es muy
ciertos riesgos de barato para ciertas
software. empresas.
6
 Unidad 2: Pruebas de Software.
Administración de las TI.

componentes de un *Ayuda a rastrear los *Se tiene que rediseñar y

sistema que han sufrido errores hasta la fuente. probar nuevamente el
modificaciones en cuanto software completo en
*Aumenta la efectividad
a su funcionalidad y ya algunas ocasiones ya que
del sistema al encontrar
habían sido probados con los defectos. muchas ves los
anterioridad, para poder componentes del mismo
detectar cualquier defecto no son los adecuados.
introducido. *Puede ocasionar efectos
negativos en otras partes
de código.

2.- Con base en la información de la tabla, deberás realizar un análisis

comparativo y definir en qué situación recomendarías cada una de ellas.  

*En el caso de las Pruebas Unitarias, considero que se tienen que aplicar en el
proceso de las pruebas de caja negra ya que como se comenta entre sus
desventajas, se encuentra que en algoritmos más complejos puede resultar mucho
más tardado alcanzarlo y algunos procesos se pueden combinar con procesos de
caja negra.

*En el caso de las Pruebas de aceptación, podemos considerar que estas se

deben aplicar a todos los software, más que nada porque este ya es el último filtro
para saber si el software checado cumple con los estándares y es totalmente
funcional.

*En el caso de las pruebas de caja blanca, podemos determinar que se tiene que
poner a prueba cuando un software tiene un error de funcionamiento, claro que
puede ser una desventaja el tener que reescribir el código sin embargo podemos
denotar que en algunos casos esto es para mejorarlo y automatizar los procesos e
incluso hacerlo mucho más funcional.

7
 Unidad 2: Pruebas de Software.
Administración de las TI.

*En el caso de las pruebas de caja negra, es un proceso importante también, ya

que se va a enfocar primordialmente en la información que envía cada función y
no tanto en su denotación. Esto resulta útil en caso de que se presenten flujos
externos de información por vías equivocadas.

*En el caso de las pruebas de regresión resultará útil aplicarla si se ha realizado

algún cambio en los componentes del producto, para poder definir si estos
cambios resultaron favorables o no.

3.- Selecciona las pruebas de software esenciales, es decir, aquellas que

consideras que deben aplicarse en la mayoría de los desarrollos de
software. 

A mi punto de vista, de los tipos de pruebas de Software que puedo considerar la

más importante son las pruebas de aceptación, ya que como es el proceso final
para saber si el software presenta alguna falla, es cierto que algunas veces
pasamos por alto algunos errores y casi siempre los podemos ver reflejados en el
momento final de la prueba. Por esto mismo podemos decir que estas pruebas
son las más importantes, sin claro dejar de lado que las otras pruebas listadas
también son importantes para diferentes procesos.

Concusiones:

En este trabajo tengo que decir que me costó un poco captarlo más que nada
porque en la mayoría de las fuentes de información que consulté la información es
totalmente distinta, nunca caían realmente en un punto en común. Sin embargo,
ahora mismo puedo comprender que para testear un programa de Software es
importante saber que no solo es un procedimiento ni una sola prueba sino son
varias pruebas de las cuales obtendremos información correcta del funcionamiento
del software.

Fuentes de información:
-programacionymas.com (N.D). Los diferentes tipos de testing en el desarrollo
de software. Recuperado de https://programacionymas.com/blog/tipos-de-
testing-en-desarrollo-de-software

8
 Unidad 2: Pruebas de Software.
Administración de las TI.

-cgrw01.cgr.go.cr (ND). Concepto prueba de aceptación. Recuperado de

https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/conce
pts/acceptance_testing_12A0F152.html
-dehesa.unex.es (Julio 2017). Testing temprano. Característica, ventajas e
inconvenientes. Experiencias Reales. Recuperado de
http://dehesa.unex.es/bitstream/handle/10662/6618/TFGUEX_2017_Tena_Gomez.p
df?sequence=1&isAllowed=y
-Pruebas de rendimiento en la nube (Globe, 2012).
-Pruebas de Software (Portnov, M, 2010).
-Pruebas Unitarias (Cruz-Ramirez, I, 2013).
-Testing funcional con Python (Schvezov, S, 2012).