Pruebas del Software Objetivos Cules son las alternativas para verificar y validar software Qu son las pruebas

uebas de software Conocer la utilidad de las pruebas unitarias Conocimientos bsicos de cmo hacer pruebas unitarias Idea bsica sobre desarrollo guiado por pruebas

Contenidos Conceptos fundamentales

Verificacin:

Consiste

en

responder

la

pregunta:

Estamos

construyendo

el

producto correctamente? Dada la especificacin que hemos tomado del usuario estamos construyendo bien el cdigo? El resultado final del desarrollo software concuerda con la especificacin (requisitos) del sistema? Hay que intentar asegurar que el desarrollo final coincide con dicha especificacin

Validacin:

Estamos construyendo el producto correcto? El resultado final del desarrollo software se ajusta a lo que el usuario quera (sus necesidades)? En la mayora de las ocasiones el producto desarrollado no casa con la ideas del cliente, normalmente porque a ste suele faltarle capacidad tcnica de expresin.

Cmo llevar a cabo la verificacin y validacin? Mtodos

Pruebas del software (Dinmico): consisten en ejecutar comprobando que distintos valores de entrada producen los resultados deseados. Mtodos de inspeccin del software (Esttico) : se basan en la revisin de la documentacin, requisitos, incluso cdigo sin ejecutar nada. Esta tarea puede realizarse por un grupo de expertos por ejemplo. o Hay un tipo concreto de mtodos estticos llamados mtodos formales. stos se basan en realizar una especificacin llevada al extremo transformando el

software a lenguaje matemtico, donde no quedan ambigedades y el cdigo queda bien especificado. o Otra forma de inspeccin del software es comprobando el cdigo mediante heursticas con algn programa que la aplica (P. ej.- Findbugs). Pruebas del software

Tipos de prueba (categorizacin)

En funcin de qu conocemos: o Pruebas de caja negra: no conocemos la implementacin del cdigo, slo la interfaz. Tan slo podemos probar dando distintos valores a las entradas y salidas. o Pruebas de caja blanca: conocemos el cdigo (la implementacin de ste) que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles caminos del cdigo.

Segn el grado de automatizacin: o Pruebas manuales: son las que se hacen normalmente al programar o las que ejecuta una persona con la documentacin generada durante la codificacin (P. ej.- comprobar cmo se visualiza el contenido de una pgina web en dos navegadores diferentes). o Pruebas automticas: se usa un determinado software para sistematizar las pruebas y obtener los resultados de las mismas (P. ej.- verificar un mtodo de ordenacin).

En funcin de qu se prueba: o Pruebas unitarias: se aplican a un componente del software. Podemos considerar como componente (elemento indivisible) a una funcin, una clase, una librera, etc. En nuestro caso, generalmente hablaremos de una clase como componente de software. o Pruebas de integracin: consiste en construir el sistema a partir de los distintos componentes y probarlo con todos integrados. Estas pruebas deven realizarse progresivamente. o Pruebas funcionales: sobre el sistema funcionando se comprueba que cumple con la especificacin (normalmente a travs de los casos de uso). o Pruebas de rendimiento: los tres primeros tipos de pruebas de los que ya se ha hablado comprueban la eficacia del sistema. Las pruebas de rendimiento se basan en comprobar que el sistema puede soportar el volumen de carga definido en la especificacin, es decir, hay que comprobar la eficiencia (P. ej.-

Se ha montado una pgina web sobre un servidor y hay que probar qu capacidad tiene estado de aceptar peticiones). o Pruebas de aceptacin: son las nicas pruebas que son realizadas por los usuarios, todas las anteriores las lleva a cabo el equipo de desarrollo. Podemos distinguir entre dos pruebas: Pruebas alfa: las realiza el usuario en presencia de personal de desarrollo del proyecto haciendo uso de una mquina preparada para tal fin. Pruebas beta: las realiza el usuario despus de que el equipo de desarrollo les entregue una versin casi definitiva del producto.

Otros conceptos relacionados con las pruebas de software

Completitud: nos da una idea del grado de fiabilidad de las pruebas y por consiguiente la fiabilidad del software. No es posible llegar al 100% puesto que nunca llegaremos a realizar todas las pruebas posibles al software, puesto que las pruebas tienen un coste (P. ej.- Bug del Excel).

Depuracin: ejecucin controlada del software que nos permite corregir un error (P. ej.- Usar el debugger de nuestra mquina). Pruebas de regresin: consiste en volver a aplicar pruebas que se haban superado anteriormente (P. ej.- Pruebas de integracin).

Pruebas unitarias automatizadas

Por qu pruebas unitarias?

Ms exhaustivas: implica hacer pruebas por clase, funcin, etc., es decir, por la unidad mnima que se haya considerado. Probar trozos de cdigo sin esperar al resto. Nos da ms confianza para modificar cdigo: se pierde el miedo a hacer modificaciones y volver inconsistente el sistema. Mejora la API: podemos darnos cuenta de fallos en la interfaz de la clase en pasos prematuros, evitando as el coste que supone una modificacin en fases ms avanzadas.

Sirve como documentacin de ejemplos de uso de la clase. Engancha cuando ves que tu cdigo pasa todas las pruebas.

Qu probamos?

Segn el tipo de componente: o Funciones individuales o mtodos de objeto: probar las entradas y las salidas y comprobar que los valores obtenidos son los esperados. o Clases de objetos: o Hacer pruebas aisladas de operaciones Probar tambin las secuencias de las operaciones.

Componentes Se tratan igual que una clase de objeto Hay que tener en cuenta si son distribuidos, en este caso es recomendable pasarle al componente pruebas de estrs.

No olvidar probar tambin el manejo de errores!

Segn en qu aspecto nos centramos: o Pruebas unitarias de cdigo aislado: Independientes del resto del sistema. En la prctica esto no es posible en la mayora de ocasiones, puesto que las clases interactan entre s. Para esto lo que se hace es sustituir los componentes por otros "de mentira" (mocks), para evitar as las dependencias. o Pruebas unitarias de integracin: se prueba cada componente, pero dentro del todo de la aplicacin, no como elemento aislado

Cmo hacemos las pruebas unitarias?

Pruebas estructurales: son Pruebas de caja blanca (no nos centraremos en estas). Pruebas de particiones: son pruebas de caja negra. Consisten en dividir las posibles entradas y salidas en conjuntos de caractersticas similares. Se identificarn los casos especiales y por ejemplo, los lmites sern sometidos a pruebas siempre. Consejos a tener en cuenta a la hora de probar valores: o o Probar siempre los lmites. Cuando tenemos listas, vectores, tablas: o Probar pistas de un solo valor y listas vacas. Probar siempre distintos tamaos. Comprobar primer elemento, el elemento central y el ltimo elemento.

Pasar null en vez del objeto.

Donde ejecutamos las pruebas unitarias?

En java podemos usar JUnit para las pruebas unitarias y JMeter para pruebas de rendimiento. Para otros lenguajes existen herramientas similares.

Cundo implementamos las pruebas unitarias?

De forma paralela a la codificacin (clase - prueba). Antes de la codificacin siguiendo un desarrollo guiado por pruebas (punto siguiente).

Desarrollo guiado por pruebas (TDD - Test-Driven Development)

Se basa en la filosofa de nicamente escribir nuevo cdigo cuando una prueba unitaria falle o para eliminar cdigo duplicado. (P. ej.- probar la interfaz de login antes de codificar las clases que interactan con la BD). (Se toman los mdulos ms importantes que compondrn el software, se programan y se integran. Se prueba que funcionen correctamente y entonces se cogen otros mdulos y se comienza de nuevo el proceso).

Desarrollo habitual:

Test-Driven Development:

Refactorizar: reorganizar, limpiar el cdigo, etc. sin alterar la funcionalidad de ste.

Programacin gil: esta metodologa de trabajo consiste en irse centrando en los requisitos del sistema por orden de importancia: llevar a cabo las pruebas y la codificacin partiendo de los requisitos ms exigidos por el cliente, presentndole stos segn se han ido implementando, y a partir de ah ir integrando requisitos en orden descendente de relevancia.

Ventajas del TDD:

Comprensin. Documentacin. Evitar sobreingeniera.

Conclusiones

Nunca un producto software se ha terminado de probar. Hay que establecer un lmite dependiendo de la trascendencia, costes, etc. del proyecto. La superacin de las pruebas no implica que no existan errores, sino que no se han detectado. Las pruebas del software no garantizan la calidad de ste: las pruebas demuestran la calidad pero no la garantizan.

Bibliografa Bsica (de referencia): o Sommerville, Ian. "Ingeniera del Software", Captulo 23. 7 Edicin, PearsonAddison Wesley, 2005. De apoyo: o Pressman, R.S."Ingeniera del Software: un enfoque prctico", Captulos 13 y 14.6 Edicin, McGraw-Hill. o Massol, Vicent. "JUnit in Action, Manning.