DAW ED03 Vers Imprimible PDF
DAW ED03 Vers Imprimible PDF
08/07/2013
Pgina 2 de 31
Caso prctico
Todos en la empresa estn inmersos en el desarrollo de la aplicacin de
gestin hotelera. Para garantizar la correccin del desarrollo, Ada
propone establecer la planificacin de las pruebas. Por qu hay que
probar el software? Es necesario seguir un orden concreto en la
realizacin de pruebas? Qu pruebas se realizan?
Durante todo el proceso de desarrollo de software, desde la fase de diseo, en la implementacin y una vez
desarrollada la aplicacin, es necesario realizar un conjunto de
pruebas, que permitan verificar que el
software que se est creando, es correcto y cumple con las especificaciones impuesta por el usuario.
En el proceso de desarrollo de software, nos vamos a encontrar con un conjunto de actividades, donde es muy
fcil que se produzca un error humano. Estos errores humanos pueden ser: una incorrecta especificacin de
los objetivos, errores producidos durante el proceso de diseo y errores que aparecen en la fase de desarrollo.
Mediante la realizacin de pruebas se software, se van a realizar las tareas
de
verificacin y
validacin del software. La verificacin es la
comprobacin que un sistema o parte de un sistema, cumple con las
condiciones impuestas. Con la verificacin se comprueba si la aplicacin
se est construyendo correctamente. La validacin es el proceso de
evaluacin del sistema o de uno de sus componentes, para determinar si
satisface los requisitos especificados.
Para llevar a cabo el proceso de pruebas, de manera eficiente, es
necesario implementar una estrategia de pruebas. Siguiendo el
Modelo
en Espiral, las pruebas empezaran con la prueba de unidad, donde se
analizara el cdigo implementado y seguiramos en la prueba de
integracin, donde se prestan atencin al diseo y la construccin de la arquitectura del software. El siguiente
paso sera la prueba de validacin, donde se comprueba que el sistema construido cumple con lo establecido
en el anlisis de requisitos de software. Finalmente se alcanza la prueba de sistema que verifica el
funcionamiento total del software y otros elementos del sistema.
08/07/2013
Pgina 3 de 31
Caso prctico
Juan y Mara estn implementando la mayor parte de la
aplicacin. Es correcto lo realizado hasta ahora? Cmo se
prueba los valores devueltos por una funcin o mtodo? Es
posible seguir la ejecucin de un programa, y ver si toma los
caminos diseados?
No existe una clasificacin oficial o formal, sobre los diversos tipos de pruebas de software. En la ingeniera del
software, nos encontramos con dos enfoques fundamentales:
Prueba de la Caja Negra (Black Box Testing): cuando una
aplicacin es probada usando su interfaz externa, sin
preocuparnos de la implementacin de la misma. Aqu lo
fundamental es comprobar que los resultados de la ejecucin
de la aplicacin, son los esperados, en funcin de las entradas
que recibe.
Prueba de la Caja Blanca (White Box Testing): en este caso,
se prueba la aplicacin desde dentro, usando su lgica de
aplicacin.
Una prueba de tipo Caja Negra se lleva a cabo sin tener que conocer ni la estructura, ni el funcionamiento
interno del sistema. Cuando se realiza este tipo de pruebas, solo se conocen las entradas adecuadas que
deber recibir la aplicacin, as como las salidas que les correspondan, pero no se conoce el proceso mediante
el cual la aplicacin obtiene esos resultados.
En contraposicin a lo anterior, una prueba de Caja Blanca, va a analizar y probar directamente el cdigo de la
aplicacin. Como se deriva de lo anterior, para llevar a cabo una prueba de Caja Blanca, es necesario un
conocimiento especfico del cdigo, para poder analizar los resultados de las pruebas.
08/07/2013
Pgina 4 de 31
Reflexiona
Resulta habitual, que en una empresa de desarrollo de software se gaste el 40 por ciento del
esfuerzo de desarrollo en la prueba Por qu es tan importante la prueba? Qu tipos de errores
se intentan solucionar con las pruebas?
08/07/2013
Pgina 5 de 31
2.1.- Funcionales.
Estamos ante pruebas de la caja negra. Se trata de probar, si las salidas
que devuelve la aplicacin, o parte de ella, son las esperadas, en funcin
de los parmetros de entrada que le pasemos. No nos interesa la
implementacin del
software, solo si realiza las funciones que se
esperan de l.
Las pruebas funcionales siguen el enfoque de las pruebas de Caja Negra.
Comprenderan aquellas actividades cuyo objetivo sea verificar una accin
especfica o funcional dentro del cdigo de una aplicacin. Las pruebas
funcionales intentaran responder a las preguntas puede el usuario hacer
esto? o funciona esta utilidad de la aplicacin?
Su principal cometido, va a consistir, en comprobar el correcto funcionamiento de los componentes de la
aplicacin informtica. Para realizar este tipo de pruebas, se deben analizar las entradas y las salidas de cada
componente, verificando que el resultado es el esperado. Solo se van a considerar las entradas y salidas del
sistema, sin preocuparnos por la estructura interna del mismo.
Si por ejemplo, estamos implementando una aplicacin que realiza un determinado clculo cientfico, en el
enfoque de las pruebas funcionales, solo nos interesa verificar que ante una determinada entrada a ese
programa el resultado de la ejecucin del mismo devuelve como resultado los datos esperados. Este tipo de
prueba, no considerara, en ningn caso, el cdigo desarrollado, ni el
algoritmo, ni la eficiencia, ni si hay
partes del cdigo innecesarias, etc.
Dentro de las pruebas funcionales, podemos indicar tres tipos de pruebas:
Particiones equivalentes: La idea de este tipo de pruebas funcionales, es considerar el menor nmero
posible de casos de pruebas, para ello, cada caso de prueba tiene que abarcar el mayor nmero
posible de entradas diferentes. Lo que se pretende, es crear un conjunto de clases de equivalencia,
donde la prueba de un valor representativo de la misma, en cuanto a la verificacin de errores, sera
extrapolable al que se conseguira probando cualquier valor de la clase.
Anlisis de valores lmite: En este caso, a la hora de implementar un caso de prueba, se van a elegir
como valores de entrada, aquellos que se encuentra en el lmite de las clases de equivalencia.
Pruebas aleatorias: Consiste en generar entradas aleatorias para la aplicacin que hay que probar. Se
suelen utilizar generadores de prueba, que son capaces de crear un volumen de casos de prueba al
azar, con los que ser alimentada la aplicacin. Esta tipo de pruebas, se suelen utilizar en
aplicaciones que no sean interactivas, ya que es muy difcil generar las secuencias de entrada
adecuadas de prueba, para entornos interactivos.
Existe otros tipos de pruebas funcionales, aunque todas comparten un mismo objetivo, y es comprobar, solo
actuando en la interfaz de la aplicacin, que los resultados que produce son los correctos en funcin de las
entradas que se le introducen para probarlos.
08/07/2013
Pgina 6 de 31
2.2.- Estructurales.
Ya hemos visto que las pruebas funcionales se centran en
resultados, en lo que la aplicacin hace, pero no en cmo lo hace.
Para ver cmo el programa se va ejecutando, y as comprobar su
correccin, se utilizan las pruebas estructurales, que se fijan en los
caminos que se pueden recorrer:
Las pruebas estructurales son el conjunto de pruebas de la Caja
Blanca. Con este tipo de pruebas, se pretende verificar la estructura
interna de cada componente de la aplicacin, independientemente de
la funcionalidad establecida para el mismo. Este tipo de pruebas, no
pretenden comprobar la correccin de los resultados producidos por
los distintos componentes, su funcin es comprobar que se van a
ejecutar todas la instrucciones del programa, que no hay cdigo no usado, comprobar que los caminos lgicos
del programa se van a recorrer, etc.
Este tipo de pruebas, se basan en unos criterios de cobertura lgica, cuyo cumplimiento determina la mayor o
menor seguridad en la deteccin de errores. Los criterios de cobertura que se siguen son:
Cobertura de sentencias: se han de generar casos de pruebas suficientes para que cada instruccin
del programa sea ejecutada, al menos, una vez.
Cobertura de decisiones: se trata de crear los suficientes casos de prueba para que cada opcin
resultado de una prueba lgica del programa, se evale al menos una vez a cierto y otra a falso.
Cobertura de condiciones: se trata de crear los suficientes casos de prueba para que cada elemento
de una condicin, se evale al menos una vez a falso y otra a verdadero.
Cobertura de condiciones y decisiones: consiste en cumplir simultneamente las dos anteriores.
Cobertura de caminos: es el criterio ms importante. Establece que se debe ejecutar al menos una
vez cada secuencia de sentencias encadenadas, desde la sentencia inicial del programa, hasta su
sentencia final. La ejecucin de este conjunto de sentencias, se conoce como camino. Como el nmero
de caminos que puede tener una aplicacin, puede ser muy grande, para realizar esta prueba, se
reduce el nmero a lo que se conoce como camino prueba.
Cobertura del camino de prueba: Se pueden realizar dos variantes, una indica que cada bucle se
debe ejecutar slo una vez, ya que hacerlo ms veces no aumenta la efectividad de la prueba y otra
que recomienda que se pruebe cada bucle tres veces: la primera sin entrar en su interior, otra
ejecutndolo una vez y otra ms ejecutndolo dos veces.
Autoevaluacin
En las pruebas de caja negra:
Es necesario conocer el cdigo fuente del programa, para realizar las pruebas.
Se comprueba que todos los caminos del programa, se pueden recorrer, al menos una vez.
Se comprueba que los resultados de una aplicacin, son los esperados para las entradas
que se le han proporcionado.
Es incompatible con la prueba de caja blanca.
08/07/2013
Pgina 7 de 31
2.3.- Regresin.
Durante el proceso de prueba, tendremos xito si detectamos un
posible fallo o error. La consecuencia directa de ese descubrimiento,
supone la modificacin del componente donde se ha detectado. Esta
modificacin, puede generar errores colaterales, que no existan
antes. Como consecuencia, la modificacin realizada nos obliga a
repetir pruebas que hemos realizado con anterioridad.
El objetivo de las pruebas de regresin, es comprobar que los
cambios sobre un componente de una aplicacin, no introduce un
comportamiento no deseado o errores adicionales en otros componentes no modificados.
Las pruebas de regresin se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto
para corregir un error, como para realizar una mejora. No es suficiente probar slo los componentes
modificados o aadidos, o las
funciones que en ellos se realizan, sino que tambin es necesario
controlar que las modificaciones no produzcan efectos negativos sobre el mismo u otros componentes.
Normalmente, este tipo de pruebas implica la repeticin de las pruebas que ya se hayan realizado
previamente, con el fin de asegurar que no se introducen errores que puedan comprometer el funcionamiento
de otros componentes que no han sido modificados y confirmar que el sistema funciona correctamente una vez
realizados los cambios.
En un contexto ms amplio, las pruebas de software con xito, son aquellas que dan como resultado el
descubrimiento de errores. Como consecuencia del descubrimiento de errores, se procede a su correccin, lo
que implica la modificacin de algn componente del software que se est desarrollando, tanto del programa,
de la documentacin y de los datos que lo soportan. La prueba de regresin es la que nos ayuda a asegurar
que estos cambios no introducen un comportamiento no deseado o errores adicionales. La prueba de
regresin se puede hacer manualmente, volviendo a realizar un subconjunto de todos los casos de prueba o
utilizando herramientas automticas.
El conjunto de pruebas de regresin contiene tres clases diferentes de clases de prueba:
Una muestra representativa de pruebas que ejercite todas las funciones del software;
Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente
afectadas por el cambio;
Pruebas que se centran en los componentes del software que han cambiado.
Para evitar que el nmero de pruebas de regresin crezca demasiado, se deben de disear para incluir slo
aquellas pruebas que traten una o ms clases de errores en cada una de las funciones principales del
programa. No es prctico ni eficiente volver a ejecutar cada prueba de cada funcin del programa despus de
un cambio.
Autoevaluacin
La prueba de regresin:
Se realiza una vez finalizado cada
08/07/2013
Pgina 8 de 31
Caso prctico
En BK, ya tienen el proyecto bastante avanzado. Ahora llega
una parte clave: definir las partes del sistema que se van a
probar y establecer los casos de prueba para realizarla. Ana va
procedimientos y
a participar, pero cuando se habla de
casos de prueba, se siente perdida. A ella le va a tocar ejecutar
los casos de prueba.
08/07/2013
Pgina 9 de 31
Caso prctico
Juan y Mara tiene muchas lneas de cdigo implementadas.
Como programadores de la aplicacin, juegan un papel
decisivo en la fase de pruebas. Al realizar este proyecto
utilizando un entorno de desarrollo integrado (NetBeans),
cuenta con una herramienta fundamental, el depurador.
realizar
pruebas
tanto
estructurales
como
Autoevaluacin
Que concepto est relacionado con la prueba de caja negra?
Es la principal herramienta de validacin.
Se pueden comprobar los valores que van tomando las variables
Se comprueba que todos los caminos del programa, se pueden recorrer, al menos una vez.
08/07/2013
Pgina 10 de 31
Es incompatible con la prueba de caja blanca.
08/07/2013
Pgina 11 de 31
08/07/2013
Pgina 12 de 31
Los distintos modos de ejecucin, se van a ajustar a las necesidades de depuracin que
tengamos en cada momento. Si hemos probada un mtodo, y sabemos que funciona
correctamente, no es necesario realizar una ejecucin paso a paso en l.
En el IDE NetBeans, dentro del men de depuracin, podemos seleccionar los modos de ejecucin
especificados, y algunos ms. El objetivo es poder examinar todas la partes que se consideren necesarias, de
manera rpida, sencilla y los ms clara posible.
08/07/2013
Pgina 13 de 31
Debes conocer
Autoevaluacin
Qu afirmacin sobre depuracin es incorrecta?
En la depuracin, podemos inspeccionar las instrucciones que va ejecutando el programa.
No es posible conocer los valores que toman las variables definidas dentro de un mtodo.
08/07/2013
Pgina 14 de 31
Solo podemos insertar un punto de ruptura en la depuracin
08/07/2013
Pgina 15 de 31
5.- Validaciones.
Caso prctico
Durante todo el proceso de desarrollo, existe una permanente
comunicacin entre Ada y su equipo, con representantes de la empresa
a la que va destinado el proyecto. Ana y Juan van a asistir a la siguiente
reunin, donde se va a mostrar a los representantes de la empresa, las
fases de proyectos ya implementadas. Ser la primera reunin de
validacin del proyecto.
requisitos.
La validacin del software se consigue mediante una serie de pruebas de caja negra que demuestran la
conformidad con los requisitos. Un plan de prueba traza la clase de pruebas que se han de llevar a cabo, y un
procedimiento de prueba define los casos de prueba especficos en un intento por descubrir errores de
acuerdo con los requisitos. Tanto el plan como el procedimiento estarn diseados para asegurar que se
satisfacen todos los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que las
documentaciones son correctas e inteligible y que se alcanzan otros requisitos, como
portabilidad,
compatibilidad, recuperacin de errores, facilidad de mantenimiento etc.
Cuando se procede con cada caso de prueba de validacin, puede darse una de las dos condiciones
siguientes:
Las caractersticas de funcionamiento o rendimiento estn de acuerdo con las especificaciones y son
aceptables o
Se descubre una desviacin de las especificaciones y se crea una lista de deficiencias. Las
desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de la
terminacin planificada.
08/07/2013
Pgina 16 de 31
Caso prctico
Juan y Mara prueban cada parte de cdigo que estn implementando.
Algunos mtodos requieren una comprobacin de su estructura interna,
en otros, valdra con probar los resultados que devuelven. Antonio se
pregunta en que consiste cada prueba, y como se lleva a cabo en la
prctica.
Para saber ms
Puedes visitar la siguiente pgina web, donde se detallan los tipos de pruebas que suelen hacer al
software y la funcin de cada una.
Pruebas de software (340.80 KB)
Autoevaluacin
Durante la validacin:
Procedemos a depurar el programa.
08/07/2013
Pgina 17 de 31
Sometemos el cdigo a pruebas de cubrimiento.
Comprobamos que la aplicacin cumple los requerimientos del cliente.
08/07/2013
Pgina 18 de 31
6.1.- Cubrimiento.
Esta tarea la realiza el programador o programadora y consiste en comprobar que los caminos
definidos en el cdigo, se pueden llegar a recorrer.
Este tipo de prueba, es de caja blanca, ya que nos vamos a centrar en el cdigo de nuestra aplicacin.
Con este tipo de prueba, lo que se pretende, es comprobar que todas las funciones, sentencias, decisiones, y
condiciones, se van a ejecutar.
Por ejemplo
Considerando que esta funcin forma parte de un programa mayor, se
considera lo siguiente:
Si durante la ejecucin del programa, la funcin es llamada, al
menos una vez, el cubrimiento de la funcin es satisfecho.
El cubrimiento de sentencias para esta funcin, ser satisfecho si
es invocada, por ejemplo como prueba(1,1), ya que en esta caso,
cada lnea de la funcin se ejecuta, incluida z=x;
Si invocamos a la funcin con prueba(1,1) y prueba(0,1), se
satisfar el cubrimiento de decisin. En el primer caso, la if
condicin va a ser verdadera, se va a ejecutar z=x, pero en el
segundo caso, no.
El cubrimiento de condicin puede satisfacerse si probamos con prueba(1,1), prueba(1,0) y prueba(0,0).
En los dos primeros casos (x<0) se evala a verdad mientras que en el tercero, se evala a falso. Al
mismo tiempo, el primer caso hace (y>0) verdad, mientras el tercero lo hace falso.
Existen otra serie de criterios, para comprobar el cubrimiento.
Secuencia lineal de cdigo y salto.
JJ-Path Cubrimiento.
Cubrimiento de entrada y salida.
Existen herramientas comerciales y tambin de software libre, que permiten realizar la pruebas de cubrimiento,
entre ellas, para Java, nos encontramos con Clover.
08/07/2013
Pgina 19 de 31
Autoevaluacin
Si en un bucle while la condicin es while (x>5 && x < 10), siendo x un valor single, sera valores
lmite
4 y 11
4,99 y 11
4,99 y 9,99.
08/07/2013
Pgina 20 de 31
08/07/2013
Pgina 21 de 31
Caso prctico
Las aplicaciones que desarrolla BK Programacin, se caracterizan por
cumplir todos los estndares de calidad de la industria. Como no poda
ser de otro modo, a la hora de realizar las pruebas, tambin van a seguir
losestndares ms actuales del mercado. Ada se va a encargar de
supervisar el cumplimiento de los estndares ms actuales.
Los estndares que se han venido utilizando en la fase de prueba de software son:
Estndares BSI
BS 7925-1, Pruebas de software. Parte 1. Vocabulario.
BS 7925-2, Pruebas de software. Parte 2. Pruebas de los componentes software.
Estndares IEEE de pruebas de software.:
IEEE estndar 829, Documentacin de la prueba de software.
IEEE estndar 1008, Pruebas de unidad
Otros estndares ISO / IEC 12207, 15289
Otros estndares sectoriales
Sin embargo, estos estndares no cubren determinadas facetas de la
fase de pruebas, como son la organizacin el proceso y gestin de
las pruebas, presentan pocas pruebas funcionales y no funcionales
etc. Ante esta problemtica, la industria ha desarrollado la norma
ISO/IEC 29119.
La norma ISO/IEC 29119 de prueba de software, pretende unificar en
una nica norma, todos los estndares, de forma que proporcione
vocabulario, procesos, documentacin y tcnicas para cubrir todo el
ciclo de vida del software. Desde estrategias de prueba para la organizacin y polticas de prueba, prueba de
proyecto al anlisis de casos de prueba, diseo, ejecucin e informe. Con este estndar, se podr realizar
cualquier prueba para cualquier proyecto de desarrollo o mantenimiento de software.
Debes conocer
Norma ISO/IEC 29119
Para saber ms
En el siguiente enlace podrs visitar la pgina internacional, donde se detallan las normas a seguir,
por las pruebas de software:
08/07/2013
Pgina 22 de 31
Normas para la prueba de software
Autoevaluacin
Qu norma de calidad intenta unificar los estndares para pruebas de software?
BS 7925-1.
IEEE 1008.
ISO/IEC 29119.
08/07/2013
Pgina 23 de 31
Caso prctico
Antonio est un poco confuso. La aplicacin que estn diseando Juan
y Mara es ya de cierta envergadura y se pregunta por la labor ingente
que queda, solo para probar todos los componentes de la aplicacin.
Mara le tranquiliza y le comenta que los Entornos de Desarrollo
actuales, incorporan herramientas que realizan la pruebas de cada
mtodo, de forma automtica.
08/07/2013
Pgina 24 de 31
08/07/2013
Pgina 25 de 31
Autoevaluacin
Las herramientas de automatizacin de pruebas ms extendida para Java es:
Junit.
FoxUnit.
Simple Test.
08/07/2013
Pgina 26 de 31
Caso prctico
Juan est realizando pruebas de la unidad, es decir, comprueba el
correcto funcionamiento de los mtodos que ha implantado. Para ello,
utiliza las herramienta de prueba incorporadas en el entorno de
desarrollo. En sucaso, ya que est utilizando NetBeans, se decanta por
Junit. Ana est muy interesada en conocer esta herramienta, que ayuda
notablemente en el proceso de pruebas.
Debes conocer
08/07/2013
Pgina 27 de 31
Para saber ms
En el siguiente enlace nos encontramos con un ejempo completo de prueba de la unidad con
NetBeans
Creacin de Casos de Prueba en NetBeans con Junit
08/07/2013
Pgina 28 de 31
Caso prctico
BK Programacin, al igual que en todas la fase de diseo de un sistema,
en la fase de prueba realiza la documentacin. Ada, como coordinadora,
le pide a Ana que ayuda a realizar la documentacin de la prueba, y le
pide que se repase la metodologa Mtrica v.3 y ayude a Mara y a Juan
en la labor de documentacin.
Para saber ms
En el siguiente enlace podrs visitar la pgina de Ministerio de Poltica Territorial y Administracin
Pblica, dedicada a Mtrica v.3
08/07/2013
Pgina 29 de 31
Mtrica v.3
Autoevaluacin
La documentacin de la prueba:
Es una labor voluntaria que se puede realizar al final del proceso de pruebas
Cada equipo de pruebas decide qu documenta y cmo.
En Espaa se usa Mtrica v.3
08/07/2013
Pgina 30 de 31
08/07/2013
Pgina 31 de 31
Recurso (2)
Autora:Ebnz
Licencia:Creative
Commons. Genrica
de
Atribucin/CompartirIgual 3,0
Procedencia:Montaje
sobre
http://es.wikipedia.org/
Autora:Oracle
Corporation
Licencia:
Copyright
cita
Procedencia: Captura
de
pantalla
de
Netbeans
Autora:Oracle Corporation
Licencia:Copyright cita
Procedencia:Captura de pantalla de Netbeans
Autora:Oracle
Corporation
Licencia:Copyright
cita
Procedencia:Captura
de
pantalla
de
Netbeans
Autora:Scott Schram.
Licencia:CC by dominio pblico.
Procedencia:www.flickr.com
Autora:Oracle
Corporation
Licencia:Copyright
cita
Procedencia:Captura
de
pantalla
de
Netbeans
Autora:JaulaDeArdilla
Licencia:CC by-nc-nd
Procedencia:http://www.flickr.com/photos/jauladeard
08/07/2013