Está en la página 1de 2

Las pruebas de software, en inglés testing son los procesos que permiten verific

ar y revelar la calidad de un producto software. Son utilizadas para identificar


posibles fallos de implementación, calidad, o usabilidad de un programa de orde
nador. Así se ejecuta un programa y mediante técnicas experimentales se trata de
descubrir que errores tiene.
Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que
permitan comprobar el grado de cumplimiento respecto de las especificaciones in
iciales del sistema.
En la cadena de valor del desarrollo de un software específico, el proceso de pr
ueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad
, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un product
o bien desarrollado. Las aplicaciones de software han crecido en complejidad y t
amaño, y por consiguiente también en costos. Hoy en día es crucial verificar y e
valuar la calidad de lo construido de modo de minimizar el costo de su reparació
n. Mientras antes se detecte una falla, más barata es su corrección.
El proceso de prueba es un proceso técnico especializado de investigación que re
quiere de profesionales altamente capacitados en lenguajes de desarrollo, método
s y técnicas de pruebas y herramientas especializadas. El conocimiento que debe
manejar un ingeniero de prueba es muchas veces superior al del desarrollador de
software
TIPOS DE PRUEBAS
• Pruebas unitarias
En programación, una prueba unitaria es una forma de probar el correcto funciona
miento de un módulo de código. Esto sirve para asegurar que cada uno de los módu
los funcione correctamente por separado. Luego, con las Pruebas de Integración,
se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestió
n.
• Pruebas de Integración
Pruebas integrales o pruebas de integración son aquellas que se realizan en el á
mbito del desarrollo de software una vez que se han aprobado las pruebas unitari
as. Consiste en realizar pruebas para verificar que un gran conjunto de partes d
e software funcionan juntos. Son las pruebas posteriores a las pruebas unitarias
y preceden el testeo de sistema.
• Pruebas de validación
Las pruebas de validación en la ingeniería de software son el proceso de revisió
n que el sistema de software producido cumple con las especificaciones y que cum
ple su cometido. Es normalmente una parte del proceso de pruebas de software de
un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones,
y tutoriales. La validación es el proceso de comprobar lo que se ha especificad
o es lo que el usuario realmente quería.
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo
para determinar si satisface los requisitos iniciales. La pregunta a realizarse
es: ¿Es esto lo que el cliente quiere?.
• Caja blanca (sistemas)
En programación, se denomina cajas blancas a un tipo de pruebas de software que
se realiza sobre las funciones internas de un módulo. Así como las pruebas de ca
ja negra ejercitan los requisitos funcionales desde el exterior del módulo, las
de caja blanca están dirigidas a las funciones internas. Entre las técnicas usad
as se encuentran; la cobertura de caminos (pruebas que hagan que se recorran tod
os los posibles caminos de ejecución), pruebas sobre las expresiones lógico-arit
méticas, pruebas de camino de datos (definición-uso de variables), comprobación
de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las it
eraciones máximas, máximas menos uno y más uno.
Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo con
creto, para luego realizar las de caja negra sobre varios subsistemas (integraci
ón).
• Caja negra (sistemas)
En teoría de sistemas y física, se denomina caja negra a aquel elemento que es e
studiado desde el punto de vista de las entradas que recibe y las salidas o resp
uestas que produce, sin tener en cuenta su funcionamiento interno. En otras pala
bras, de una caja negra nos interesará su forma de interactuar con el medio que
le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) en
tendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto
, de una caja negra deben estar muy bien definidas sus entradas y salidas, es de
cir, su interfaz; en cambio, no se precisa definir ni conocer los detalles inter
nos de su funcionamiento
• Pruebas de regresión
Se denominan Pruebas de regresión a cualquier tipo de pruebas de software que in
tentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad
, o divergencias funcionales con respecto al comportamiento esperado del softwar
e, inducidos por cambios recientemente realizados en partes de la aplicación que
anteriormente al citado cambio no eran propensas a este tipo de error. Esto imp
lica que el error tratado se reproduce como consecuencia inesperada del citado c
ambio en el programa.
TIPOS DE REGRESION
Clasificación de ámbito
• Local - los cambios introducen nuevos errores.
• Desenmascarada - los cambios revelan errores previos.
• Remota - Los cambios vinculan algunas partes del programa (módulo) e int
roducen errores en ella.
Clasificación temporal
• Nueva característica - los cambios realizados con respecto a nuevas func
ionalidades en la versión introducen errores en otras novedades en la misma vers
ión del software.
• Característica preexistente - los cambios realizados con respecto a nuev
as funcionalidades introducen errores en funcionalidad existente de previas vers
iones