VERIFICACIN Y VALIDACIN DEL

SOFTWARE
Enero 2015

INTRODUCCIN

La prueba del software es un elemento crtico para la garanta de la calidad del

software y representa una revisin final de las especificaciones, del diseo y de la
codificacin.

La prueba de software es un elemento que a menudo se le conoce como

verificacin y validacin (V & V).

Bohem lo define:
Verificacin: Estamos construyendo el software correctamente?
Validacin: Estamos construyendo el producto correcto?

Ingeniera del Software

OBJETIVOS DE LA PRUEBA

La prueba es un proceso de ejecucin de un programa con la intencin de descubrir

un error.

Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un
error no descubierto hasta entonces.

Una prueba tiene xito si descubre un error no detectado hasta entonces.

La prueba no puede asegurar la ausencia de defectos, slo puede

demostrar que existen defectos en el software.

Ingeniera del Software

PRINCIPIOS DE LA PRUEBA

Las pruebas debern planificarse mucho antes de que empiecen para garantizar la
calidad de acuerdo a lo establecido en el ciclo de vida en V.

Las pruebas debern empezar por lo pequeo y progresar hacia lo grande.

No son posibles las pruebas exhaustivas.

Para ser ms efectivas, las pruebas debern ser conducidas por un equipo
independiente.

Ingeniera del Software

Pruebas de SW
Para determinar el nivel de calidad se deben efectuar
unas medidas o pruebas que permitan comprobar el
grado
de
cumplimiento
respecto
de
las
especificaciones iniciales del sistema.
Las pruebas de software, testing o beta testing es un
proceso usado para identificar posibles fallos de
implementacin, calidad, o usabilidad de un programa.
Bsicamente es una fase en el desarrollo de software
consistente en probar las aplicaciones construidas.
"El testing puede probar la presencia de errores pero
no la ausencia de ellos", E. W. Dijkstra.

Pruebas de SW
Una definicin de "testing" es:
proceso de evaluacin de un producto desde
un punto de vista crtico, donde el "tester"
(persona que realiza las pruebas) somete el
producto a una serie de acciones inquisitivas,
y
el
producto
responde
con
su
comportamiento como reaccin.
Por supuesto, nunca se debe testear el
software en un entorno de produccin

La importancia de la deteccin
oportuna
En la cadena de valor del desarrollo de un software
especfico, el proceso de prueba es clave a la hora de
detectar errores o fallas.
Conceptos como estabilidad, escalabilidad, eficiencia y
seguridad se relacionan a la calidad de un producto
bien desarrollado. Las aplicaciones de software han
crecido en complejidad y tamao, y por consiguiente
tambin en costos.
Hoy en da es crucial verificar y evaluar la calidad de lo
construido de modo de minimizar el costo de su
reparacin.

La importancia de la deteccin
oportuna
Mientras antes se detecte una falla, ms barato
es su correccin.
El proceso de prueba es un proceso tcnico
especializado de investigacin que requiere de
profesionales altamente capacitados en lenguajes
de desarrollo, mtodos y tcnicas de pruebas y
herramientas especializadas.
El conocimiento que debe manejar un ingeniero
de prueba es muchas veces superior al del
desarrollador de software.

La importancia de la deteccin
oportuna..cont

Checar el programa contra las especificaciones.

Encontrar errores en el programa.
Determinar el grado de aceptabilidad para el usuario.
Asegurarse de que un sistema est listo para usarse.
Ganar confidencia de que el programa funciona.
Mostrar que un programa funciona correctamente.
Demostrar que los errores no estn presentes.
Entender los lmites del rendimiento.
Aprender lo que el sistema no puede hacer.
Evaluar las capacidades de un sistema.
Verificar la documentacin.
Convencerse a uno mismo de que el trabajo ya est terminado.

PRUEBAS DE UNIDAD

La prueba de unidad centra el proceso de verificacin en la menor unidad del

diseo del software: el mdulo.
Usando la descripcin del diseo procedimental como gua, se prueban los caminos
de control importantes, con el fin de descubrir errores dentro del lmite del mdulo.
La prueba de unidad est orientada a caja blanca y este paso se puede llevar a cabo
en paralelo para mltiples mdulos.

Ingeniera del Software

PRUEBAS DE UNIDAD

La prueba de unidad centra el proceso de verificacin en la menor unidad del

diseo del software: el mdulo.
Usando la descripcin del diseo procedimental como gua, se prueban los caminos
de control importantes, con el fin de descubrir errores dentro del lmite del mdulo.
La prueba de unidad est orientada a caja blanca y este paso se puede llevar a cabo
en paralelo para mltiples mdulos.

Ingeniera del Software

Tipos de pruebas

Pruebas unitarias
Pruebas funcionales
Pruebas de Integracin
Pruebas de validacin
Pruebas de sistema
Caja blanca (sistemas)
Caja negra (sistemas)
Pruebas de aceptacin
Pruebas de regresin
Pruebas de carga
Pruebas de prestaciones
Pruebas de recorrido
Pruebas de mutacin

PRUEBAS UNITARIAS

La prueba de unidad centra el proceso de verificacin en la menor unidad del

diseo del software: el mdulo.
Usando la descripcin del diseo procedimental como gua, se prueban los caminos
de control importantes, con el fin de descubrir errores dentro del lmite del mdulo.
La prueba de unidad est orientada a caja blanca y este paso se puede llevar a cabo
en paralelo para mltiples mdulos.

Ingeniera del Software

Prueba Unitaria
Para que una prueba unitaria sea buena se deben cumplir los
siguientes requisitos:
Automatizable: no debera requerirse una intervencin manual.
Esto es especialmente til para integracin continua.
Completas: deben cubrir la mayor cantidad de cdigo.
Repetibles o Reutilizables: no se deben crear pruebas que slo
puedan ser ejecutadas una sola vez. Tambin es til para
integracin continua.
Independientes: la ejecucin de una prueba no debe afectar a la
ejecucin de otra.
Profesionales: las pruebas deben ser consideradas igual que el
cdigo, con la misma profesionalidad, documentacin, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la
letra, se recomienda seguirlos o de lo contrario las pruebas pierden
parte de su funcin.

Ventajas
El objetivo de las pruebas unitarias es aislar cada parte del
programa y mostrar que las partes individuales son correctas.
Proporcionan un contrato escrito que el trozo de cdigo debe
satisfacer. Estas pruebas aisladas proporcionan cinco ventajas
bsicas:
Fomentan el cambio: Las pruebas unitarias facilitan que el
programador cambie el cdigo para mejorar su estructura, puesto
que permiten hacer pruebas sobre los cambios y as asegurarse de
que los nuevos cambios no han introducido errores.
Simplifica la integracin: Puesto que permiten llegar a la fase de
integracin con un grado alto de seguridad de que el cdigo est
funcionando correctamente.

Ventajas
Documenta el cdigo: Las propias pruebas son documentacin del
cdigo puesto que ah se puede ver cmo utilizarlo.
Separacin de la interfaz y la implementacin: Dado que la nica
interaccin entre los casos de prueba y las unidades bajo prueba
son las interfaces de estas ltimas, se puede cambiar cualquiera de
los dos sin afectar al otro
Los errores estn ms acotados y son ms fciles de localizar:
dado que tenemos
pruebas unitarias que pueden
desenmascararlos.

Pruebas funcionales
Una prueba funcional es una prueba basada
en la ejecucin, revisin y retroalimentacin
de las funcionalidades previamente diseadas
para el software.
La pruebas funcionales se hacen mediante el
diseo de modelos de prueba que buscan
evaluar cada una de las opciones con las que
cuenta el paquete informtico.

Pruebas integrales
Pruebas integrales o pruebas de integracin son aquellas que se
realizan en el mbito del desarrollo de software una vez que se han
aprobado las pruebas unitarias.
nicamente se refieren a la prueba o pruebas de todos los
elementos unitarios que componen un proceso, hecha en conjunto,
de una sola vez.
Consiste en realizar pruebas para verificar que un gran conjunto de
partes de software funcionan juntos.
Las pruebas de integracin (algunas veces llamadas integracin y
testeo I&t) es la fase del testeo de software en la cual mdulos
individuales de software son combinados y testeados como un
grupo.
Son las pruebas posteriores a las pruebas unitarias y preceden el
testeo de sistema.

Pruebas de validacin
Las pruebas de validacin en la ingeniera de software son el
proceso de revisin que el sistema de software producido cumple
con las especificaciones y que cumple su cometido.
Es normalmente una parte del proceso de pruebas de software de
un proyecto, que tambin utiliza tcnicas tales como evaluaciones,
inspecciones, y tutoriales.
La validacin es el proceso de comprobar lo que se ha especificado
es lo que el usuario realmente quera.
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 programacin, se denomina cajas blancas a un tipo de pruebas de
software que se realiza sobre las funciones internas de un mdulo.
Estn dirigidas a las funciones internas.
Entre las tcnicas usadas se encuentran; la cobertura de caminos (pruebas
que hagan que se recorran todos los posibles caminos de ejecucin),
pruebas sobre las expresiones lgico-aritmticas, pruebas de camino de
datos (definicin-uso de variables), comprobacin de bucles (se verifican
los bucles para 0,1 y n iteraciones, y luego para las iteraciones mximas,
mximas menos uno y ms uno.
Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un
mdulo concreto,
En los sistemas orientados a objetos, las pruebas de caja blanca pueden
aplicarse a los mtodos de la clase, pero segn varias opiniones, ese
esfuerzo debera dedicarse a otro tipo de pruebas ms especializadas
Este concepto tambin es utilizado de manera anloga en la teora general
de sistemas.

Caja negra (sistemas)

En teora de sistemas y fsica, se denomina caja negra a
aquel elemento que es estudiado desde el punto de vista
de las entradas que recibe y las salidas o respuestas que
produce, sin tener en cuenta su funcionamiento interno.
En otras palabras, de una caja negra nos interesar su
forma de interactuar con el medio que le rodea (en
ocasiones, otros elementos que tambin podran ser cajas
negras) entendiendo qu es lo que hace, pero sin dar
importancia a cmo lo hace.
Por tanto, de una caja negra deben estar muy bien
definidas sus entradas y salidas, es decir, su interfaz; en
cambio, no se precisa definir ni conocer los detalles
internos de su funcionamiento.

Pruebas de regresin
Se denominan Pruebas de regresin a cualquier tipo de pruebas de
software que intentan descubrir las causas de nuevos errores
(bugs), carencias de funcionalidad, o divergencias funcionales con
respecto al comportamiento esperado del software, inducidos por
cambios recientemente realizados en partes de la aplicacin que
anteriormente al citado cambio no eran propensas a este tipo de
error.
Esto implica que el error tratado se reproduce como consecuencia
inesperada del citado cambio en el programa.
Este tipo de cambio puede ser debido a prcticas no adecuadas de
control de versiones, falta de consideracin acerca del mbito o
contexto de produccin final y extensibilidad del error que fue
corregido (fragilidad de la correccin), o simplemente una
consecuencia del rediseo de la aplicacin.

Pruebas de regresin
Por lo tanto, en la mayora de las situaciones del
desarrollo de software se considera una buena prctica
que cuando se localiza y corrige un bug, se grabe una
prueba que exponga el bug y se vuelvan a probar
regularmente despus de los cambios subsiguientes
que experimente el programa.
Existen herramientas de software que permiten
detectar este tipo de errores de manera parcial o
totalmente automatizada, la prctica habitual en
programacin extrema es que este tipo de pruebas se
ejecuten en cada uno de los pasos del ciclo de vida del
desarrollo del software.

Tipos de regresin
Clasificacin de mbito
Local - los cambios introducen nuevos errores.
Desenmascarada - los cambios revelan errores previos.
Remota - Los cambios vinculan algunas partes del
programa (mdulo) e introducen errores en ella.

Clasificacin temporal
Nueva caracterstica - los cambios realizados con respecto
a nuevas funcionalidades en la versin introducen errores
en otras novedades en la misma versin del software.
Caracterstica preexistente - los cambios realizados con
respecto a nuevas funcionalidades introducen errores en
funcionalidad existente de previas versiones.

Caso de prueba
En Ingeniera del software, los casos de prueba o Test Case son un
conjunto de condiciones o variables bajo las cules el analista
determinar si el requisito de una aplicacin es parcial o
completamente satisfactorio.
Se pueden realizar muchos casos de prueba para determinar que un
requisito es completamente satisfactorio. Con el propsito de
comprobar que todos los requisitos de una aplicacin son
revisados, debe haber al menos un caso de prueba para cada
requisito a menos que un requisito tenga requisitos secundarios. En
ese caso, cada requisito secundario deber tener por lo menos un
caso de prueba.
Algunas metodologas como RUP recomiendan el crear por lo
menos dos casos de prueba para cada requisito. Uno de ellos debe
realizar la prueba positiva de los requisitos y el otro debe realizar la
prueba negativa.

Caso de prueba
Si la aplicacin es creada sin requisitos formales, entonces los
casos de prueba se escriben basados en la operacin normal
de programas de una clase similar.
Lo que caracteriza un escrito formal de caso de prueba es que
hay una entrada conocida y una salida esperada, los cuales
son formulados antes de que se ejecute la prueba. La entrada
conocida debe probar una precondicin y la salida esperada
debe probar una postcondicin.

Caso de prueba

La entrada conocida debe probar una precondicin y la salida

esperada debe probar una postcondicin.
Bajo circunstancias especiales, podra haber la necesidad de
ejecutar la prueba, producir resultados, y luego un equipo de
expertos evaluara si los resultados se pueden considerar como
"Correctos".
Esto sucede a menudo en la determinacin del nmero del
rendimiento de productos nuevos. La primera prueba se toma
como lnea base para los subsecuentes ciclos de
pruebas/lanzamiento del producto.
Los casos de prueba escritos, incluyen una descripcin de la
funcionalidad que se probar, la cul es tomada ya sea de los
requisitos o de los casos de uso, y la preparacin requerida para
asegurarse de que la prueba pueda ser dirigida.

Caso de prueba
Los casos de prueba escritos se recogen generalmente en una
suite de pruebas.
Las variaciones de los casos de prueba son comnmente
utilizados en pruebas de aceptacin.
La prueba de aceptacin es realizada por un grupo de
usuarios finales o los clientes del sistema, para asegurarse que
el sistema desarrollado cumple sus requisitos. La prueba de
aceptacin de usuario se distingue generalmente por la
incorporacin de un trayecto feliz o casos de prueba positivos.

Estructura de los casos de prueba

Formalmente, los casos de prueba escritos consisten principalmente en
tres partes con subdivisiones:
Introduccin/visin general contiene informacin general acerca de los
Casos de Prueba.
Identificador es un identificador nico para futuras referencias, por
ejemplo, mientras se describe un defecto encontrado.
Caso de prueba dueo/creador es el nombre del analista o diseador
de pruebas, quien ha desarrollado pruebas o es responsable de su
desarrollo.
Versin la actual definicin del caso de prueba.
Nombre el caso de prueba debe ser un ttulo entendible por personas,
para la fcil comprensin del propsito del caso de prueba y su campo
de aplicacin.

Estructura de los casos de prueba

Identificador de requerimientos el cul est incluido por el caso de
prueba. Tambin aqu puede ser identificador de casos de uso o
especificacin funcional.
Propsito contiene una breve descripcin del propsito de la prueba,
y la funcionalidad que chequea.
Dependencias
Actividad de los casos de prueba
Ambiente de prueba/configuracin contiene informacin acerca de la
configuracin del hardware o software en el cul se ejecutar el caso
de prueba.
Inicializacin describe acciones, que deben ser ejecutadas antes de
que los casos de prueba se hayan inicializado. Por ejemplo, debemos
abrir algn archivo.

Estructura de los casos de prueba

Finalizacin describe acciones, que deben ser ejecutadas despus de
realizado el caso de prueba. Por ejemplo si el caso de prueba estropea
la base de datos, el analista debe restaurarla antes de que otro caso
de prueba sea ejecutado.
Acciones pasos a realizar para completar la prueba.
Descripcin de los datos de entrada
Resultados
Resultados esperados contiene una descripcin de lo que el analista
debera ver tras haber completado todos los pasos de la prueba
Resultados reales contienen una breve descripcin de lo que el
analista encuentra despus de que los pasos de prueba se hayan
completado. Esto se sustituye a menudo con un Correcto/Fallido. Si
un caso de prueba falla, frecuentemente la referencia al defecto
implicado se debe enumerar en esta columna.

Desarrollo guiado por pruebas

Desarrollo guiado por pruebas, o Test-driven development (TDD)
es una prctica de programacin que involucra otras dos prcticas:
Escribir las pruebas primero (Test First Development) y
Refactorizacin (Refactoring).
Para escribir las pruebas generalmente se utilizan las pruebas
unitarias (unit test en ingls).
Primero se escribe una prueba y se verifica que las pruebas fallen,
luego se implementa el cdigo que haga que la prueba pase
satisfactoriamente y seguidamente se refactoriza el cdigo escrito.
El propsito del desarrollo guiado por pruebas es lograr un cdigo
limpio que funcione (Del ingls: Clean code that works).
La idea es que los requerimientos sean traducidos a pruebas, de
este modo, cuando las pruebas pasen se garantizar que los
requerimientos se hayan implementado correctamente.

Ciclo De Desarrollo Conducido por

Pruebas
Antes de comenzar el ciclo se debe definir una lista de requerimientos.
Luego se comienza el siguiente ciclo:
Elegir un requerimiento: Se elige de una lista el requrimiento que se cree
que nos dar mayor conocimiento del problema y que a la vez sea
fcilmente implementable.
Escribir una prueba: Se comienza escribiendo una prueba para el
requerimiento. Para ello el programador debe entender claramente las
especificaciones y los requisitos de la funcionalidad que est por
implementar. Este paso fuerza al programador a tomar la perspectiva de
un cliente considerando el cdigo a travs de sus interfaces.
Verificar que la prueba falla: Si la prueba no falla es porque el
requerimiento ya estaba implementado o porque la prueba es errnea.
Escribir la implementacin: Escribir el cdigo ms sencillo que haga que la
prueba funcione. Se usa la metfora "Djelo simple" ("Keep It Simple).

Ciclo De Desarrollo Conducido por

Pruebas
Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de
pruebas funciona correctamente.
Eliminacin de duplicacin: El paso final es la refactorizacin, que se
utilizar principalemente para eliminar cdigo duplicado. Se hacen de a
una vez un pequeo cambio y luego se corren las pruebas hasta que
funcionen.
Actualizacin de la lista de requerimientos: Se actualiza la lista de
requerimientos tachando el requerimiento implementado. Asimismo se
agregan requerimientos que se hayan visto como necesarios durante este
ciclo y se se agregan requerimientos de diseo (P. ej que una funcionalidad
est desacoplada de otra).

Caractersticas
Una ventaja de esta forma de programacin es el evitar escribir
cdigo innecesario ("You Ain't Gonna Need It" (YAGNI)). Se intenta
escribir el mnimo cdigo posible, y si el cdigo pasa una prueba
aunque sepamos que es incorrecto nos da una idea de que
tenemos que modificar nuestra lista de requerimientos agregando
uno nuevo.
La generacin de pruebas para cada funcionalidad hace que el
programador confe en el cdigo escrito. Esto permite hacer
modificacines profundas del cdigo (posiblemente en una etapa
de mantenimiento del programa) pues sabemos que si luego
logramos hacer pasar todas las pruebas tendremos un cdigo que
funcione correctamente.
Otra cracterstica del Test Driven Development requiere que el
programador primero haga fallar los casos de prueba. La idea es
asegurarse de que los casos de prueba realmente funcionen y
puedan recoger un error.

El Costo de las
Pruebas en el Ciclo de Vida
Estudios han demostrado que durante el ciclo de vida del software se
producen 60 errores por cada KLOC.
Estudios tambin han demostrado que testing antes de la codificacin es
50% efectivo en detectar errores y 80% efectivo despus de la
codificacin.
Estos estudios han demostrado que es 10 veces mas costoso corregir un
error en codificacin y 100 veces ms costoso en produccin.
Tambin se ha demostrado que 2 tercios de los errores ocurren antes de
la codificacin.
40% de los Costos de Desarrollo son para Pruebas