Nery Javier Machado Bez

Ingeniera de Software - UNCA

Tcnicas de prueba del

software

 La
palabra
calidad
tiene
mltiples
significados.
Es un conjunto de propiedades inherentes a
un objeto que le confieren capacidad para
satisfacer necesidades implcitas o explcitas.
La calidad de un producto o servicio es la
percepcin que el cliente tiene del mismo, es
una fijacin mental del consumidor que
asume conformidad con dicho producto o
servicio y la capacidad del mismo para
satisfacer sus necesidades
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Calidad

 Pruebas de software son los procesos

que permiten verificar y revelar la
calidad de un producto software.
Las pruebas de software se integran
dentro de las diferentes fases del Ciclo
del software dentro de la Ingeniera de
software.
As se ejecuta un programa y mediante
tcnicas experimentales se trata de
descubrir que errores tiene
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Pruebas de SW

 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

La importancia de la
deteccin oportuna

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

Nery Javier Machado Bez

Ingeniera de Software - UNCA

Tipos de pruebas

 Prueba unitaria es una forma de probar

el correcto funcionamiento de un mdulo
de cdigo.
Esto sirve para asegurar que cada uno de
los mdulos funcione correctamente por
separado.
La idea es escribir casos de prueba para
cada funcin no trivial o mtodo en el
mdulo de forma que cada caso sea
independiente del resto.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Prueba Unitaria

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Ventajas

 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Pruebas funcionales

 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Pruebas integrales

Ingeniera de Software - UNCA

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?.
Nery Javier Machado Bez

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Caja blanca (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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Caja negra (sistemas)

 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Pruebas 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Tipos de regresin

 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Caso 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

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.

Nery Javier Machado Bez

Ingeniera de Software - UNCA

Estructura de los casos

de prueba

Ingeniera de Software - UNCA

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.

Nery Javier Machado Bez

 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).
Primeros e 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Desarrollo guiado por

pruebas

Ingeniera de Software - UNCA

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, Stupid" (KISS)).
Nery Javier Machado Bez

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).

Nery Javier Machado Bez

Ingeniera de Software - UNCA

Ciclo De Desarrollo
Conducido por Pruebas

 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.
Nery Javier Machado Bez

Ingeniera de Software - UNCA

Caractersticas