TEMA 5:

OPTIMIZACIN

DEL

SOFTWARE

Contenido Introduccin .................................................................................................................................. 4

1. Diseo y realizacin de pruebas de software ........................................................................ 5

1.1 Introduccin .................................................................................................................. 5

1.2 Las pruebas en el ciclo de vida de un proyecto ......................................................... 6

1.3 Procedimientos, tipos y casos de pruebas ................................................................ 7

1.3.1 Planificacin de las pruebas ....................................................................................... 8

1.3.2 Diseo de las pruebas. Tipos de pruebas ............................................................ 10

1.3.3 Ejecucin de las pruebas ..................................................................................... 38

1.3.4 Finalizacin: evaluacin y anlisis de errores ...................................................... 40

1.3.5 Depuracin del cdigo fuente ............................................................................. 41

1.4 Herramientas para la realizacin de pruebas .............................................................. 44

1.4.1 Beneficios y problemas del uso de herramientas de pruebas ............................ 44

1.4.2 Algunas herramientas de pruebas de software .................................................. 45

2. Herramientas para el control y documentacin de software.............................................. 47

Introduccin Un usuario final de una aplicacin informtica no es conocedor de cmo ha sido implementada

ni codificada. Lo ms importante para l o ella es que esta aplicacin haga lo que tenga que

hacer, y, adems, que lo haga en el menor tiempo posible. Qu importancia tendr para un

usuario utilizar dos productos que, en definitiva, ofrecen las mismas caractersticas?

Imaginemos el caso de dos televisores. Si los dos reproducen los mismos canales y tienen las

mismas pulgadas e idnticas caractersticas tcnicas, que nos har decidir si usar uno u otro?

Posiblemente, en el caso de los televisores habr intangibles, como la marca o la esttica u

otras caractersticas subjetivas. Pero, en el caso de las aplicaciones informticas o de las

pginas web, cul puede ser el elemento que haga que una sea mejor que la otra si hacen

exactamente lo mismo y tienen las mismas interfaces?

En el caso del software, todo esto es algo abstracto; habr muchos intangibles que pueden

hacer decantar hacia una aplicacin o hacia otra. Pero lo que seguro que ser diferente es la

forma de haber creado y desarrollado estas aplicaciones.

En esta unidad, "Optimizacin de software", veremos estas diferencias entre un cdigo de

programacin normal y un cdigo optimizado, y estudiaremos las caractersticas que

diferencian un tipo de cdigo de otro y las herramientas de las que se puede disponer para ello

En el apartado "Diseo y realizacin de pruebas de software" se explican las diferentes formas

y tcnicas que permiten validar la correccin del software desarrollado y su optimizacin. Hay

muchas formas de poder crear aplicaciones que hagan lo que tienen que hacer y que cumplan

los requisitos establecidos para los futuros usuarios. Y muchas veces, las diferencias en el

momento de la creacin y del desarrollo de las aplicaciones harn que una se pueda considerar

mucho mejor que la otra, y por lo tanto recomendable.

Qu significa haber desarrollado mejor una aplicacin informtica? Significar que su cdigo

de programacin sea ptimo, que haya seguido los patrones de optimizacin ms

recomendados, que se hayan llevado a cabo todas las pruebas que hay que hacer para validar

un funcionamiento correcto al 100%, que su desarrollo se haya documentado, habiendo un

control de versiones exhaustivo y muchos otros detalles que se vern en esta unidad formativa.

En cambio, una aplicacin informtica, sobre todo si es de cdigo abierto o se ha desarrollado a

medida para una empresa externa o por el propio departamento de informtica de una

organizacin, puede ser un producto vivo, en continua evolucin. Un da los informes se

querrn ver de una forma u otra, o habr que aadir otros nuevos, otro da las reglas de

negocio tendrn modificado y habr revisarlas para su desempeo. Otro, quizs, habr que

modificar las funcionalidades que ofrece la aplicacin, ampliarla con unas nuevas y sacar otros.

En el apartado "Herramientas para el control y documentacin del software" trabajaremos

algunas tcnicas que se utilizan para mejorar la calidad del cdigo de software por parte de los

desarrolladores. Un ejemplo es la refactorizacin, pero tambin hay otros como el control de

versiones o la documentacin automtica del software.

1. Diseo y realizacin de pruebas de software Las pruebas son necesarias en la fabricacin de cualquier producto industrial y, de forma

anloga, en el desarrollo de proyectos informticos. Quin pondra a la venta una aspiradora

sin estar seguro de que aspira correctamente? O una radio digital sin haber comprobado que

pueda sintonizar los canales?

Una aplicacin informtica no puede llegar a las manos de un usuario final con errores, y

menos si stas son suficientemente visibles y claras como para haber sido detectadas por los

desarrolladores. Se dara una situacin de falta de profesionalidad y disminuye la confianza por

parte de los usuarios, que podra mermar oportunidades futuras.

Cuando hay que llevar a cabo las pruebas? Qu hay que probar? Todas las fases establecidas

en el desarrollo del software son importantes. La falta o mala ejecucin de alguna de ellas

puede provocar que el resto del proyecto arrastre uno o varios errores que sern

determinantes para su xito. Cuanto antes se detecte un error, menos costoso ser de

solucionar.

Tambin sern muy importantes las pruebas que se llevarn a cabo una vez el proyecto est

finalizado. Es por ello que la fase de pruebas del desarrollo de un proyecto de software se

considera bsica antes de hacer la transferencia del proyecto al usuario final. Quien dara un

coche para construido y finalizado si al intentar arrancarlo no funcionara?

1.1 Introduccin Cualquier miembro del equipo de trabajo de un proyecto informtico puede cometer errores.

Los errores, adems, se podrn dar a cualquiera de las fases del proyecto (anlisis, diseo,

codificacin ...). Algunas de estas errores sern ms determinantes que otros y tendrn ms o

menos implicaciones en el desarrollo futuro del proyecto.

Por ejemplo, un jefe de proyecto, a la hora de planificar las tareas del equipo, estipula el diseo

de las interfaces en 4 horas de trabajo para un nico diseador. Si, una vez ejecutada esta tarea

del proyecto, la duracin ha sido de 8 horas y se han necesitado dos diseadores, la

repercusin en el desarrollo del proyecto ser una desviacin en tiempo y en coste, que quizs

se podr compensar utilizando menos recursos o menos tiempo en alguna tarea posterior.

En cambio, si el error ha sido del diseador de la base de datos, que ha obviado un campo

clave de una tabla principal y su vinculacin con una segunda tabla, sta puede ser mucho ms

determinante en las tareas posteriores. Si se crean las interfaces a partir de esta base de datos

errnea y se empieza a desarrollar el software sin identificar el error, puede suceder que al

cabo de unas cuantas tareas se detecte el error y que, por tanto, haya que volver al punto de

inicio para solucionarla

Las fases de desarrollo de un proyecto son: toma de requerimientos, anlisis, diseo,

desarrollo, pruebas, finalizacin y transferencia.

Un error no detectado al inicio del desarrollo de un proyecto puede llegar a necesitar cincuenta

veces ms esfuerzos para ser solucionado si es detectado a tiempo.

En un proyecto de desarrollo de software est estipulado que se dedica entre un 30% y un 50%

del coste de todo el proyecto en la fase de pruebas. Con este dato podemos darnos cuenta de

la importancia de las pruebas dentro de un proyecto. Los resultados de las pruebas podrn

influir en la percepcin que tendr el cliente final en relacin con el producto (software)

entregado y su calidad.

Precisamente, es el objetivo de estas pruebas: la evaluacin de la calidad del software

desarrollado durante todo su ciclo de vida, validando que hace lo que debe hacer y que lo hace

tal como se dise, a partir los requerimientos.

1.2 Las pruebas en el ciclo de vida de un proyecto

En cada una de las fases del ciclo de vida de un proyecto, ser necesario que el trabajo llevado

a cabo sea validado y verificado.

En el esquema de la figura 1.1 podemos ver cmo encajan las pruebas en el ciclo de vida del

software.

Figura 1.1. Ciclo de vida en V: fases de prueba

Depuradores

Los depuradores (debuggers)son una aplicaciones o herramientas permiten la ejecucin

controlada un programa o un cdigo, siguiendo el mando ejecutado y localizando los errores

(bugs) Que puedan contener.

Cuando se avanza en el desarrollo del software se van planificando las pruebas que se harn en

cada fase del proyecto. Esta planificacin se concretar en un plan de pruebas que se aplicar a

cada producto desarrollado. Cuando se detectan errores en un producto se debe volver a la

fase anterior para depurarlo y corregirlo, esto se indica con las flechas de vuelta de la parte

izquierda de la figura.

Como se puede observar en la figura 1.1, El proceso de verificacin cubrir las fases de diseo

e implementacin del producto. Las personas implicadas en su ejecucin sern los

desarrolladores o programadores y el ingeniero de pruebas.

Los desarrolladores harn pruebas sobre el cdigo y los diferentes mdulos que lo integran, y

el ingeniero, sobre el diseo del sistema.

Validacin es el trmino que se usa para evaluar positivamente si el producto desarrollado

cumple los requisitos establecidos en el anlisis. Las personas encargadas de realizar las

pruebas de validacin son los ingenieros de pruebas.

Finalmente, el cliente debe dar el visto bueno al producto, por lo que se harn las pruebas de

aceptacin en funcin de las condiciones que se firmaron al principio del contrato.

1.3 Procedimientos, tipos y casos de pruebas

En cada una de las fases de un proyecto se tendr que dedicar un tiempo considerable a

desarrollar las tareas y los procedimientos referentes a las pruebas. Es por ello que algunos

autores consideran que los procedimientos relacionados con las pruebas son como un

pequeo proyecto englobado dentro del proyecto de desarrollo.

Este proyecto de pruebas requerir de una planificacin, un diseo del plan de pruebas, una

ejecucin de las mismas y una evaluacin de los resultados, para analizar los errores y poder

aplicar las acciones necesarias. En la figura 1.2 se muestra un esquema con los procedimientos

que habr que llevar a cabo y la documentacin que se deber adjuntar. Este esquema servir

como ndice para este apartado.

El esquema se inicia con una planificacin de las pruebas, que tiene como punto de partida el

anlisis funcional, diagramas de casos de uso del producto a desarrollar. En la planificacin se

estimarn los recursos necesarios para la elaboracin de las pruebas y la posterior validacin

del software, y se obtendr un plan de pruebas como salida.

Partiendo del plan de pruebas y del cdigo fuente que se haya desarrollado, se llevar a cabo el

diseo de las pruebas identificando qu tipo de pruebas se efectuar para cada una de las

funcionalidades, y obtendrn, como salida, los casos de prueba y procedimientos. A partir de

este momento, se crea un bucle donde se ejecutarn las pruebas, se evaluarn los resultados

de las pruebas efectuadas detectando los errores, se depurar el cdigo aplicando las

correcciones pertinentes y se volvern a ejecutar las pruebas.

Al finalizar el bucle, se har el anlisis de la estadstica de errores. Este anlisis permitir hacer

predicciones de la fiabilidad del software, as como detectar las causas ms habituales de error,

con lo cual se podrn mejorar los procesos de desarrollo.

Figura 1.2. Proceso de pruebas

1.3.1 Planificacin de las pruebas

La planificacin de las pruebas es una tarea que hay que ir desarrollando a lo largo de todas las

fases del proyecto informtico. No hay que esperar la fase de programacin para crear este

plan de pruebas, en la fase de anlisis y en la fase de diseo ya se tienen suficientes datos para

poder comenzar a establecer las primeras lneas del plan de pruebas.

Es importante tener presente que, cuanto antes se detecte una error al proyecto informtico,

ms fcil ser contrarrestar y solucionar este error. El coste de la resolucin de un problema

crece exponencialmente a medida que avanzan las fases del proyecto en las que se detecte.

Pero, como sucede en muchos aspectos de la vida, una cosa es la teora y otra muy distinta la

realidad. En muchas consultoras especializadas en desarrollo de software, as como en otras

empresas ms pequeas o, incluso, por parte de programadores independientes que crean su

propio software, se consideran las pruebas como un proceso que se trata al final del proyecto,

una vez la mayor parte del cdigo ha sido desarrollado.

La planificacin de las pruebas tiene como objetivo llegar a la creacin de un plan de actuacin

que se refiera a cundo y cmo se llevarn a cabo las pruebas. Pero para ello es necesario

llevar a cabo un anlisis minucioso del sistema y de sus elementos. El plan de pruebas debe

contener todas las funciones, las estrategias, las tcnicas y los miembros del equipo de trabajo

implicados.

Una buena gua para determinar qu contendr un buen plan de pruebas se puede obtener de

la normativa IEEE 829-2008 "Standard for Software and System Test Documentation". Este

estndar establece cmo deber ser la documentacin y los procedimientos que se utilizarn

en las diferentes etapas de las pruebas del software. Algunos de los contenidos del plan de

pruebas son:

Identificador del plan de pruebas.Es el identificador que se asignar al plan de

pruebas. Es importante para poder identificar fcilmente qu alcance tiene el plan de pruebas.

Por ejemplo, si se quieren verificar las interfaces y procedimientos relacionados con la gestin

de clientes, su plan de pruebas se podra decir PlaClients.

Descripcin del plan de pruebas.Define el alcance del plan de pruebas, el tipo de

prueba y sus propiedades, as como los elementos del software que se quieren probar.

Elementos del software a probar.Determina los elementos del programa horario que

se deben tener en cuenta en el plan de pruebas, as como las condiciones mnimas que deben

cumplirse para llevarlo cabo.

Elementos del software que no se deben probar. Tambin es importante definir los

elementos que no se debern tener en cuenta el plan de pruebas.

Estrategia del plan de pruebas.Define la tcnica a utilizar en el diseo de los casos de

prueba, como por ejemplo la tcnica de caja blanca o de caja negra, as como las herramientas

que se utilizarn o, incluso, el grado de automatizacin de las pruebas.

Definicin de la configuracin del plan de pruebas.Define las circunstancias bajo las

cuales el plan de pruebas podr ser alterado, finalizado, suspendido o repetido. Cuando se

efecten las pruebas, se deber determinar cul es el punto que provoca que se suspendan, ya

que no tendra mucho sentido continuar probando el software cuando ste se encuentra en un

estado inestable. Una vez los errores han sido corregidos, se podr continuar efectuando las

pruebas, es posible que se inicien desde el principio del plan o desde una determinada prueba.

Finalmente, se podr determinar la finalizacin de las pruebas si stas han superado un

determinado umbral.

Documentos a entregar. Define los documentos a entregar durante el plan de pruebas

y al finalizarlo. Esta documentacin debe contener la informacin referente al xito o fracaso

de las pruebas ejecutadas con todo tipo de detalle. Algunos de estos documentos pueden ser:

resultados de los casos de pruebas, especificacin de las pruebas, subplanes de pruebas ...

Tareas especiales.Define las manchas necesarias para preparar y ejecutar las pruebas.

Pero hay algunas tareas que tendrn un carcter especial, por su importancia o por su

dependencia con otras. Para este tipo de tareas, ser necesario efectuar una planificacin ms

detallada y determinar bajo qu condiciones se llevarn a cabo.

Recursos. Por cada tarea definida en el plan de pruebas, deber asignarse uno o varios

recursos, que sern los encargados de llevarla a cabo.

Responsables y Responsabilidades.Se define el responsable de cada una de las tareas

previstas en el plan.

Calendario del plan de pruebas.En el calendario quedan descritas las tareas que

debern ejecutar, indicando sus dependencias, los responsables, las fechas de actuacin y la

duracin, as como las metas del plan de pruebas. Una herramienta muy utilizada para

representar este calendario del plan de pruebas es el Diagrama de Gantt.

Un error tpico es tratar la planificacin de pruebas como una actividad puntual, limitada al

periodo de tiempo en que se elabora una lista de acciones para ser desarrolladas durante los

prximos das, meses ... La planificacin es un proceso continuo y no puntual, por lo que hay

que trabajar en l a lo largo de todo el proyecto, y para ello es necesario:

Gestionar los cambios: no es de extraar que, a lo largo del ciclo de vida del proyecto, y

con mayor probabilidad cuanto ms larga es la duracin, se presenten cambios en el alcance

del proyecto. Ser necesario adaptar el plan de pruebas en las nuevas especificaciones.

Gestionar los riesgos: Un riesgo se podra definir como un conjunto de situaciones que

pueden provocar un impedimento o retraso en el plan de pruebas. Los riesgos debern

identificar lo antes posible y analizar la probabilidad que existe de que sucedan, aplicando

medidas preventivas, si se considera oportuno, o disponer de un plan de contingencia en caso

de que el riesgo surgiera.

En la planificacin de un proyecto informtico el tiempo dedicado a las pruebas suele ser muy

limitado.

De esta As, se puede afirmar que toda planificacin debe ser viva y hay que ir revisando y

controlando de forma peridica. En caso de desviacin, se deben analizar las causas que lo han

provocado y cmo afecta al resto de los proyectos.

1.3.2 Diseo de las pruebas. Tipos de pruebas

El diseo de las pruebas es el siguiente paso despus de haber llevado a cabo el plan de

pruebas. Este diseo consistir en establecer los casos de prueba, identificando, en cada caso,

el tipo de prueba que se deber efectuar.

Existen muchos tipos de pruebas:

Estructurales o de caja blanca

Funcionales o de caja negra

De integracin

De carga y aceptacin

De sistema y de seguridad

De regresin y de humo

Casos de prueba y procedimientos

A partir del plan de pruebas se debern especificado las partes de cdigo a tratar, en qu orden

habr que hacer las pruebas, quien las har y mucha informacin ms. Ahora slo falta entrar

en detalle, especificando el caso de prueba para cada una de las pruebas a realizar.

Un caso de prueba define cmo se llevarn a cabo las pruebas, especificando, entre otros: el

tipo de pruebas, las entradas de las pruebas, los resultados esperados o las condiciones bajo

las cuales debern desarrollarse.

Los casos de pruebas tienen un objetivo muy marcado: identificar los errores que hay en el

software para que stos no lleguen al usuario final. Estos errores pueden encontrarse como

defectos en la interfaz de usuario, en la ejecucin de estructuras de datos o un determinado

requisito funcional.

A la hora de disear los casos de prueba, no slo se ha de validar que la aplicacin hace lo que

se espera ante entradas correctas, sino que tambin debe validar que tenga un

comportamiento estable frente a entradas no esperadas , informando del error.

Para desarrollar y ejecutar los casos de prueba en un proyecto informtico, podemos

identificar dos enfoques:

Pruebas de caja negra: se trata de ir probando todo el proyecto de forma

independiente, funcin a funcin. El objetivo es validar que el cdigo cumple la funcionalidad

definida.

Pruebas de caja blanca: se trata de comprobar que todas las funciones encajan sin

problemas para cumplir los objetivos del proyecto, es decir, deben garantizar que todas las

piezas del proyecto encajan ajustndose a sus funcionalidades y los requerimientos

establecidos.

Podemos observar que los casos de prueba nos permiten validar la aplicacin que se est

desarrollando, siendo necesario tener accesible la documentacin generada en el anlisis

funcional y el anlisis tcnico, as como en el diseo (casos de uso, diagramas de secuencia ...).

Los casos de prueba siguen un ciclo de vida clsico:

Definicin de los casos de prueba.

Creacin de los casos de prueba.

Seleccin de los valores para los tests.

Ejecucin de los casos de prueba.

Comparacin de los resultados obtenidos con los resultados esperados.

Cada caso de prueba deber ser independiente de los dems, tendr un comienzo y un final

muy marcado y deber almacenar toda la informacin referente a su definicin, creacin,

ejecucin y validacin final.

A continuacin se indican algunas informaciones que debera contemplar cualquier caso de

prueba:

Identificador del caso de prueba.

Mdulo o funcin a probar.

Descripcin del caso de prueba detallado.

Entorno que deber cumplir antes de la ejecucin del caso de prueba.

Datos necesarios para el caso, especificando sus valores.

Tareas que ejecutar el plan de pruebas y su secuencia.

Resultado esperado.

Resultado obtenido.

Observaciones o comentarios despus de la ejecucin.

Responsable del caso de prueba.

Fecha de ejecucin.

Estado (Finalizado, pendiente, en proceso).

Todo caso de prueba est asociado, como mnimo, a un procedimiento de prueba.

Los procedimientos de prueba especifican como se podrn llevar a cabo los casos de prueba o

parte de stos de forma independiente o de forma conjunta, estableciendo las relaciones entre

ellos y el orden en que debern atender.

Por ejemplo, se puede disear un procedimiento de prueba para insertar una nueva asignatura

en la matrcula de un alumno; elaboran todos los pasos necesarios de forma consecutiva para

actualizar la matrcula del alumno. Sin embargo, la asignatura puede ser obligatoria, optativa,

con unas incompatibilidades ..., por lo tanto, en cuanto al procedimiento de prueba de insertar

la matrcula ser necesario asociar un grupo de casos de prueba responsables de las diversas

entradas de el usuario.

En la figura 1.3 se puede observar un esquema explicativo de las pruebas, desde la creacin del

plan de pruebas hasta su ejecucin. Para cada parte del proyecto ser necesario crear un

diseo de las pruebas, a partir del cual se especificarn los casos de prueba y los

procedimientos de prueba, que estn estrechamente ligados. Tras los procedimientos de

prueba, el ltimo paso ser su ejecucin.

Figura 1.3. Casos de pruebas y procedimientos

Tipos de pruebas

Existen muchos tipos de pruebas que deben cubrir las especificaciones de un proyecto

informtico a travs de los procedimientos y los casos de prueba.

A continuacin se presenta un resumen de estos tipos de pruebas:

Tipo de pruebas unitarias. Tienen las siguientes caractersticas:

Son el tipo de pruebas de bajo nivel.

Se llevan a cabo a medida que se va desarrollando el proyecto.

Las efectan los mismos programadores.

Tienen como objetivo la deteccin de errores en los datos, en los algo-mes y en

la lgica de estos.

Las pruebas unitarias se podrn llevar a cabo segn un enfoque estructural o

segn un enfoque funcional.

El mtodo utilizado en este tipo de pruebas es el de la caja blanca o el de caja

negra.

Tipo de pruebas funcionales. De estas pruebas hay que destacar:

Son las encargadas de detectar los errores en la implementacin de los

requerimientos de usuario.

Las llevarn a cabo los verificadores y los analistas, es decir, personas distintas

a aquellas que han programado el cdigo.

Se efectan durante el desarrollo del proyecto.

El tipo de mtodo utilizado es el funcional.

Tipo de pruebas de integracin. Sus caractersticas son las siguientes:

Se llevarn a cabo posteriormente a las pruebas unitarias.

Tambin las efectan los mismos programadores.

Se llevan a cabo durante el desarrollo del proyecto.

Se encargan de detectar errores de las interfaces y en las relaciones entre los

componentes.

El mtodo utilizado es el de caja blanca, el de diseo descendente y el de

bottom-up.

Tipo de pruebas de sistemas. A destacar:

Su finalidad es detectar errores en la consecucin de los requerimientos.

Las llevarn a cabo los verificadores y los analistas, es decir, personas distintas

a aquellas que han programado el cdigo.

Se efectan en una fase de desarrollo del software.

El tipo de mtodo utilizado es el funcional.

Tipo de pruebas de aceptacin. Los aspectos ms importantes de estas pruebas son

los siguientes:

Su objetivo es la validacin o aceptacin de la aplicacin por parte de los

usuarios.

Es por ello que las llevarn a cabo los verificadores y los analistas, pero tambin

los clientes, que sern los usuarios finales de las aplicaciones.

Estas pruebas se llevarn a cabo una vez finalizada la fase de desarrollo, y es

posible hacerlo en la fase previa a la finalizacin ya la transferencia o en la fase de

produccin, mientras los usuarios ya utilizan la aplicacin.

El tipo de mtodo utilizado tambin es el funcional.

Pruebas unitarias: enfoque estructural o de caja blanca

Las pruebas unitarias, tambin conocidas como pruebas de componentes, son las pruebas que

se harn a ms bajo nivel, sobre los mdulos o componentes ms pequeos del cdigo fuente

del proyecto informtico.

Estas pruebas pueden desarrollarse bajo dos enfoques:

El enfoque estructural es la parte de las pruebas unitarias encargadas de la estructura

interna del cdigo fuente, desde que se analizan todos los posibles caminos.

El enfoque funcional (o pruebas de caja negra) es la parte de las pruebas unitarias

encargadas del funcionamiento correcto de las funcionalidades del software.

Las pruebas de caja blanca se centran en la implementacin de los programas para escoger los

casos de prueba. Lo ideal sera buscar casos de prueba que recorrieran todos los caminos

posibles del flujo de control del programa. Estas pruebas se centran en la estructura interna del

programa, analizando los caminos de ejecucin.

En la figura 1.4 se puede observar un esquema de la estructura que tienen las pruebas de caja

blanca. A partir de unas condiciones de entrada al mdulo o parte de cdigo necesario validar

que, yendo por la bifurcacin que se vaya, se obtendrn las condiciones deseadas de salida.

Figura 1.4. Estructura de las pruebas de caja blanca

Las pruebas de caja blanca permitirn recorrer todos los posibles caminos del cdigo y ver qu

sucede en cada caso posible. Se probar qu ocurre con las condiciones y los bucles que se

ejecutan. Las pruebas se llevarn a cabo con datos que garanticen que han tenido lugar todas

las combinaciones posibles. Para decidir qu valores debern tomar estos datos es necesario

saber cmo se ha desarrollado el cdigo, buscando que no quede ningn rincn sin revisar.

Partiendo del hecho de que las pruebas exhaustivas son impracticables, ya que el nmero de

combinaciones es excesivo, se disean estrategias que ofrezcan una seguridad aceptable para

descubrir errores. Los mtodos que se vern dentro de las pruebas de caja blanca son el de

cobertura de flujo de control y el de complejidad Ciclomtica.

Cobertura de control de flujo

El mtodo de cobertura de flujo de control consiste en utilizar la estructura de control del

programa para obtener los casos de prueba, que son diseados de manera que garanticen que

al menos se pasa una vez por cada camino del programa.

Una posible tcnica para llevar a cabo este mtodo consiste en obtener un diagrama de flujo

de control que represente el cdigo y probar todos los caminos simples, todas las condiciones y

todos los bucles del programa. Se puede observar un ejemplo de diagrama de flujo en la figura

1.5.

Puede ser imposible cubrir el 100% si el programa es muy complejo, pero podemos tener un

mnimo de garantas de eficacia si seguimos las sugerencias para disear los casos de prueba

fijndonos en estos elementos:

Camino simple: Se ha de disear un caso de prueba para cada camino independiente,

de manera que ejecute al menos una vez cada sentencia. Para ello es necesario determinar los

posibles caminos independientes y preparar suficientes casos de prueba para recorrer todos

los caminos.

Condiciones: Deben disearse suficientes casos de prueba para todas las condi-ciones

del programa que se evalan a verdadero / falso. Si las condiciones son mltiples, debern

dividirse en expresiones simples (una para cada operando lgico o comparacin), de manera

que se debe probar que se cumpla o no cada parte de cada condicin.

Bucles: Se deben disear los casos de prueba de manera que se intente ejecutar un

bucle en diferentes situaciones lmite.

En la figura 1.5 se representan grficamente los nodos de la funcin, lo que facilita el clculo de

la complejidad Ciclomtica.

Figura 1.5. Diagrama de flujo del listado de asignaturas.

Complejidad Ciclomtica

La estrategia de cobertura de flujo de control requiere disear casos de prueba suficientes para

recorrer toda la lgica del programa. Se puede saber cuntos casos de prueba es necesario

crear y ejecutar? Cmo se calcula?

El matemtico Thomas J. McCabe llam complejidad Ciclomtica (CC) al nmero de caminos

independientes de un diagrama de flujo, y propuso la siguiente frmula para calcularla:

Complejidad Ciclomtica = nmero de ramas - nmero de nodos + 2

La complejidad Ciclomtica del grafo del ejemplo anterior, el de la figura 1.5, Proporciona el

nmero mximo de caminos linealmente independientes.

Los nodos que intervienen son 1, 2, 3, 4, 5, 6 y 7, y las ramas son las lneas que unen los nodos,

que son un total de 8.

complejidad Ciclomtica CC = 8-7 + 2 = 3

Esto significa que se debern disear tres casos de prueba. As, los tres recorridos que se

deberan tener en cuenta son:

Camino 1: 1 - 2 - 3 - 4 - 5 - 6 - 2-7

Camino 2: 1 - 2 - 3 - 4 - 6 - 2-7

Camino 3: 1 - 2-7

Quedar generar las pruebas para recorrer los caminos anteriores. En la figura 1.6 se muestran

los valores del vector de asignaturas.

Hay tres caminos a recorrer. Para cada uno de ellos ser necesario un vector con una

caractersticas concretas:

Por recorrer el camino 1 ser necesario un vector de asignaturas que contenga como

mnimo una asignatura que est disponible.

Por recorrer el camino 2 ser necesario un vector de asignaturas que contenga como

mnimo una asignatura que no est disponible.

Por recorrer el camino 3 ser necesario un vector de asignaturas vaco.

Figura 1.6. Valores del vector de asignaturas

Los resultados de las pruebas seran:

Entrada (Assignatures1)

Salida esperada: 1

Salida real: 1

Camino seguido: 1.

Entrada (Assignatures2)

Salida esperada: 1

Salida real: 1

Camino seguido: 2.

Entrada (Assignatures3)

Salida esperada: 0

Salida real: 0

Camino continuacin: 3.

Una vez ejecutado el juego de prueba de caja blanca, se puede afirmar que han sido superadas

satisfactoriamente.

Pruebas unitarias: enfoque funcional o pruebas de caja negra

El enfoque estructural o las pruebas de caja blanca, dentro de las pruebas unitarias, sirve para

analizar el cdigo en todas sus estructuras, en todos sus caminos del software. Pero existe otro

tipo de pruebas que se basa en un enfoque ms funcional, llamadas pruebas de caja negra.

Las pruebas de caja negra prueban la funcionalidad del programa, para el que se disean casos

de prueba que comprueben las especificaciones del programa.

Las tcnicas de prueba de caja negra pretenden encontrar errores en funciones incorrectas o

ausentes, errores de interfaz, errores de rendimiento, inicializacin y finalizacin. Se centra en

las funciones y en sus entradas y salidas.

En la figura 1.7 se puede observar un esquema de la estructura que tienen las pruebas de caja

blanca.

Figura 1.7. Estructura de las pruebas de caja negra

Habr que elegir cuidadosamente los casos de prueba, de manera que sean tan pocos como

sea posible para que la prueba se pueda ejecutar en un tiempo razonable y, al mismo tiempo,

que cubran la variedad de entradas y salidas ms amplia posible.

Para ello, se han diseado diferentes tcnicas:

Clases de equivalencia:se trata de determinar los diferentes tipos de entrada y salida,

agruparlos y elegir casos de prueba para cada tipo o conjunto de datos de entrada y salida.

Anlisis de los valores lmite: Estudian los valores iniciales y finales, ya que

estadsticamente se ha demostrado que tienen ms tendencia a detectar errores.

Estudio de errores tpicos: La experiencia dice que hay una serie de errores que se

suelen repetir en muchos programas, por lo que se tratara de disear casos de prueba que

provocaran las situaciones tpicas de este tipo de errores.

Manejo de interfaz grfica: Para probar el funcionamiento de las interfaces grficas, se

deben disear casos de prueba que permitan descubrir errores en el manejo de ventanas,

botones, iconos ...

Datos aleatorias:se trata de utilizar una herramienta que automatice las pruebas y que

genere de forma aleatoria los casos de prueba. Esta tcnica no optimiza la eleccin de los casos

de prueba, pero si se hace durante bastante tiempo con muchos datos, podr llegar a hacer

una prueba bastante completa. Esta tcnica se podra utilizar como complementaria a las

anteriores o en casos en que no sea posible aplicar ninguna otra.

Un ventaja de las pruebas de caja negra es que son independientes del lenguaje o paradigma

de programacin utilizado, por lo que son vlidas tanto para programacin estructurada como

para programacin orientada a objetos.

Clases de equivalencia

Se deben disear los casos de prueba de manera que prueben la mayor funcionalidad posible

del programa, pero que no incluyan demasiados valores. Por dnde empezar? Qu valores se

deben escoger?

Hay que seguir los siguientes pasos:

1. Identificar las condiciones, Restricciones o contenidos de las entradas y las salidas.

2. Identificar, a partir de las condiciones, las clases de equivalencia de las entradas y las

salidas. Para identificar las clases, el mtodo propone algunas recomendaciones:

Cada elemento de clase debe ser tratado de la misma manera por el programa,

pero cada clase debe ser tratada de manera diferente en relacin con otra clase. Esto

asegura que basta probar algn elemento de una clase para comprobar que el

programa funciona correctamente para esta clase, y tambin garantiza cubriendo

diferentes tipos de datos de entrada con cada una de las clases.

Las clases deben recoger tanto datos vlidos como errneas,ya que el

programa debe estar preparado y no bloquearse bajo ninguna circunstancia.

Si se especifica un rango de valores para los datos de entrada, por ejemplo, si

se admite del 10 al 50, se crear una clase vlida (10 X50) y dos clases no vlidas,

una para los valores superiores (X>50) y la otra para los inferiores (X

La experiencia previa del equipo de pruebas puede ayudar a escoger los casos que ms

probabilidades tienen de encontrar errores.

Anlisis de valores lmite y errores tpicos

Hay tcnicas que sirven para seleccionar mejor las clases de equivalencia. Una es el anlisis de

los valores lmite. Por qu es una tcnica adecuada fijarse especialmente en los valores

lmite?

Se ha podido demostrar que los casos de prueba que se centran en los valores lmite producen

un mejor resultado para la deteccin de defectos.

De esta forma, al escoger el elemento representativo de la clase de equivalencia, en lugar de

coger uno cualquiera, escogen los valores al lmite y, si se considera oportuno, un valor

intermedio. Adems, tambin se intenta que los valores en la entrada provoquen valores lmite

en los resultados.

A la hora de escoger los representantes de cada clase se seguirn las siguientes

recomendaciones:

En los rangos de valores, coger los extremos del rango y el valor intermedio.

Si se especifican una serie de valores, coger el superior, el inferior, el anterior a

la inferior y el posterior al superior.

Si el resultado se mueve en un determinado rango, debemos escoger datos a la

entrada para provocar las salidas mnima, mxima y un valor intermedio.

Si el programa elige una lista o tabla, coger el elemento primero, el ltimo y el

intermedio.

Tambin se puede aprovechar la experiencia previa. Hay una serie de errores que se repiten

mucho en los programas, y podra ser una buena estrategia utilizar casos de prueba que se

centren en buscar estos errores. De esta manera, se mejorar la eleccin de los representantes

de las clases de equivalencia:

El valor cero suele provocar errores, por ejemplo, una divisin por cero

bloquea el programa. Si se tiene la posibilidad de introducir ceros a la entrada, se debe

escoger en los casos de prueba.

Cuando se ha de introducir una lista de valores, habr que centrarse en la

posibilidad de no introducir ningn valor, o introducir uno.

Hay que pensar que el usuario puede introducir entradas que no son normales,

por lo que es recomendable ponerse en el peor caso.

Los desbordamientos de memoria son habituales, por eso hay que intentar

introducir valores tan grandes como sea posible.

Uso de interfaz grfica

No tan slo hay que hablar de entradas de textos, tambin hay que tener en cuenta los

entornos grficos donde se llevan a cabo las entradas de valores o donde se visualizan los

resultados.

Actualmente, la mayora de programas suelen interactuar con el usuario haciendo uso de

sistemas grficos que cada vez son ms complejos, con lo cual se pueden generar errores.

Las pruebas de interfaz grfica de usuario deben incluir:

Pruebas sobre ventanas: iconos de cerrar, minimizar ...

Pruebas sobre mens y uso de ratn.

Pruebas de entrada de datos: cuadro de texto, listas desplegables ...

Pruebas de documentacin y ayuda del programa.

Otros.

En la figura 1.9 se mostrauna ventana que controla el acceso al sistema de matriculacin de los

alumnos mediante la introduccin de un nombre de usuario y una clave (password). El sistema

comprueba si hay una cuenta con el nombre y clave especificado y, si es as, se da permiso para

entrar. Si hay una cuenta con ese nombre y la clave es incorrecta, permite volver a introducir la

clave hasta un mximo de tres veces.

Figura 1.9. Pantalla para el control de entrada del identificador del alumno y de la clave para

poder efectuar la matrcula

A continuacin se muestran algunos de los casos de prueba que se podran utilizar con este

programa:

Caso de prueba 1:

Entrada: usuario correcto y la contrasea correcta. Pulsar el botn de acceder

al sistema.

Condiciones de ejecucin: en la tabla existe este usuario con la contrasea y

con un intento fallido (nmero inferior a 3).

-Resultado esperado: dar acceso al sistema y reflejar que el nmero de intentos para el

usuario correcto es cero en la tabla USUARIO (cuenta, contrasea, n. intentos).

Caso de prueba 2:

Entrada: usuario incorrecto y contrasea correcta. Pulsar el botn de acceder al

sistema.

Condiciones de ejecucin: en la tabla no existe ese usuario con esta

contrasea.

Resultado esperado: no dar acceso al sistema.

Pruebas de integracin

Son suficientes las pruebas que se hacen en cada parte de una aplicacin para asegurarnos de

que se ha validado el funcionamiento del software? La respuesta es no, es necesario validar

tambin los diferentes mdulos combinados.

Pruebas de integracin

Una vez se han probado los componentes individuales del programa y se ha garantizado que no

contienen errores, habr integrarlos para crear un sistema completo que tambin deber ser

probado. Este es el nivel de las pruebas de integracin.

Un objetivo importante de las pruebas de integracin es localizar errores en las interfaces entre

las diferentes unidades. Adems, las pruebas de integracin sirven para validar que las partes

de cdigo que ya han sido probadas de forma independiente continen funcionando

correctamente al ser integradas.

Los elementos no se integran todos al mismo tiempo, sino que se utilizan diferentes estrategias

de integracin incremental, que, bsicamente, consisten en el que se muestra en el flujo de la

figura 01:10.

Figura 1.1o. Esquema de integracin incremental

Con este proceso se facilita la localizacin del error cuando se produzca, porque se sabe cules

son los ltimos mdulos que se han integrado y cuando se produjo el error.

La organizacin clsica de los mdulos es una estructura jerrquica organizada por niveles: en

la parte alta estar el mdulo o mdulos principales (a veces denominados padres), que hacen

llamadas a mdulos subordinados de nivel inferior (hijos), y as sucesivamente cada nivel

utilizar mdulos de nivel inferior hasta llegar a los mdulos terminales. Los mdulos

superiores sern los ms cercanos al usuario, es decir, incluyen la interfaz de usuario (entorno

grfico, mens, ayudas ...), y los mdulos inferiores son los ms cercanos a la estructura fsica

del aplicacin (bases de datos, hardware ...).

Existen diferentes estrategias de desarrollo de pruebas de integracin, como son las pruebas

de integracin ascendente y las pruebas de integracin incrementales descendientes.

Prueba de integracin ascendente

Esta estrategia de desarrollo de las pruebas de integracin comenzar por los mdulos finales,

los mdulos de ms bajo nivel, agrupndolos por sus funcionalidades. Se crear un mdulo

impulsor que ir efectuando llamadas a los diferentes mdulos a partir de las precondiciones

indicadas y recogiendo los resultados de cada llamada a cada funcin.

A medida que los resultados de estas pruebas vayan saliendo positivos, se ir escalando por el

rbol de jerarquas con el mdulo impulsor hacia los otros mdulos, haciendo las llamadas

pertinentes de forma recursiva. La ltima prueba ser una llamada al software entero con los

valores de entrada reales (analizando los valores tambin reales de salida).

A continuacin, se describe el proceso seguido para un sistema de informacin que tiene una

estructura como la que se muestra en la figura 01:11:

Figura 1.11. Esquema de pruebas de integracin ascendentes

En la figura 1.12 se puede observar la primera fase de las pruebas de integracin ascendentes.

Cada mdulo debe ser probado por separado, por eso hay que construir un mdulo impulsor

independiente para probar cada mdulo.

Figura 01:12. Integracin incremental ascendente, fase 1

La figura 01:13 muestra la siguiente fase, una vez finalizadas las pruebas sobre los mdulos de

nivel ms bajo, los mdulos (07, 08, 12, 13, 14 y 11). El siguiente paso es continuar con los

mdulos del siguiente nivel. Pero esto implica crear nuevos mdulos impulsores (04, 09, 10 y

06), que se aplicarn a estos mdulos, los cuales se integrarn con los mdulos de nivel ms

bajo anteriormente probados (07, 08, 12, 13, 14 y 11).

Figura 01.13. Integracin incremental ascendente, fase 2

La figura 1:14 muestra un nivel ms de esta estrategia, llegando a los mdulos 02, 05 y 03.

Figura 1:14. Integracin incremental ascendente, fase 3

En la figura 1.15 se ve la integracin de los mdulos 04 y 05 con el mdulo 02, para lo cual se

deber crear el impulsor 02, que llamar a este mdulo.

Figura 1:15. Integracin incremental ascendente, fase 4

En la figura 1.16 se ve como llega al final de este ejemplo de integracin incremental

ascendente, hasta el mdulo 01, que integra los mdulos 02 y 03. Tambin habr que crear un

impulsor 01 para la llamada de este mdulo.

Figura 1.16. Integracin incremental ascendente, fase 5

Adaptando el ejemplo que se trata en los puntos anteriores a las pruebas de integracin, si se

quisieran efectuar las pruebas del proceso de matriculacin de los alumnos en un centro

universitario, se podra empezar por los mdulos que hacen cambios en la base de datos o en

el XML donde se almacena la informacin. Una vez que cada uno de estos mdulos funciona

correctamente, se inician las pruebas de los mdulos de nivel superior, que bsicamente hacen

llamadas a estos mdulos de nivel ms bajo (mdulos que podran tener la lgica de negocio).

De forma progresiva, se irn incorporando nuevos mdulos hasta probar todo el sistema.

Ventajas de la integracin incremental ascendente

Las ventajas son las siguientes:

Orden adecuado: primero se evalan los mdulos inferiores, que son los que

suelen tener el procesamiento ms complejo, se solucionan los errores, y luego se

nutre de datos del resto del sistema.

Ms sencillez: las entradas para las pruebas son ms fciles de crear, ya que los

mdulos inferiores suelen tener funciones ms especficas.

Mejor observacin de los resultados de las pruebas: como se empieza por los

mdulos inferiores, es ms fcil la observacin de los resultados de las pruebas.

Desventajas de la integracin incremental ascendente

Entre las desventajas, cabe destacar:

Anlisis parcial: hasta que no se hace la llamada al ltimo mdulo no se valida

el sistema como tal.

Alto tiempo de dedicacin: habr que dedicar mucho tiempo a implementar

cada mdulo impulsor, que pueden llegar a ser muchos.

Prueba de integracin incremental descendente

Esta estrategia de desarrollo de las pruebas de integracin comenzar por el mdulo de control

principal (el ms importante, el de mayor nivel). Una vez validado, se irn integrando los otros

mdulos que dependen de forma progresiva, sin seguir una estrategia concreta, slo teniendo

en cuenta que el nuevo mdulo incorporado a las pruebas tendr ya validados todos los

mdulos que lo referencian. En funcin del tipo de mdulos y del tipo de proyecto, se escoger

una secuencia u otra a la hora de ir integrando mdulos, analizando el problema concreto. Las

etapas de la integracin descendente son:

Se selecciona el mdulo ms importante, el de mayor nivel. Este mdulo har

de impulsor. Habr escribir otros mdulos ficticios que simulen los mdulos que

llamar el principal.

A medida que se van integrando mdulos, deber probarse

independientemente y de forma conjunta con los otros mdulos ya probados. Una vez

se ha finalizado la prueba, se sustituye el mdulo ficticio creado por el real que se ha

integrado.

Ahora habr que escribir los mdulos ficticios subordinados que se necesiten

para la prueba del nuevo mdulo incorporado.

En la figura 01:17 se puede observar un esquema a partir del cual se llevarn a cabo las

pruebas de integracin incremental descendente. En primer lugar, se combinarn los mdulos

para formar los grupos 1, 2 y 3. Sobre cada grupo debern llevar a cabo las pruebas mediante

un controlador. Los mdulos de los grupos 1 y 2 son subordinados del mdulo 02. Igualmente,

se deber eliminar el controlador 3 del grupo 3 antes de la integracin con el mdulo 03. A

continuacin, se integrar el mdulo 01 con el mdulo 02 y el mdulo 03. Estas acciones se

irn repitiendo de forma recursiva a lo largo de toda la estructura del proyecto.

Figura 01.17. Prueba de integracin incremental descendente

Ventajas de la integracin descendente

Las ventajas son las siguientes:

Identificacin de la estructura: permite ver la estructura del sistema desde un

principio, facilitando la elaboracin de demostraciones de su funcionamiento.

Diseo descendente: primero se definen las interfaces de los diferentes

subsistemas para luego seguir con las funciones especficas de cada uno por separado.

Deteccin ms rpida de los errores que se encuentren en los mdulos

superiores por el hecho de detectarse en una etapa inicial.

Desventajas de la integracin descendente

Entre las desventajas, destaca:

Coste muy elevado: se implementarn muchos mdulos adicionales para

ofrecer los mdulos ficticios a fin de ir efectuando las pruebas.

Alta dificultad: al querer hacer una distribucin de las pruebas del ms

genrico a lo ms detallado, los datos que se debern utilizar son difciles de conseguir,

ya que son los mdulos de nivel ms bajo los que tendrn los detalles.

Pruebas de carga y aceptacin

El siguiente paso, una vez hechas las pruebas unitarias y las pruebas de integracin, ser llevar

a cabo primero las pruebas de carga y, posteriormente, las pruebas de aceptacin.

Las pruebas de carga son pruebas que tienen como objetivo comprobar el rendimiento y la

integridad de la aplicacin ya terminada con datos reales. Se trata de simular el entorno de

explotacin de la aplicacin.

Con las pruebas anteriores (unitarias y de integracin) quedara probada la aplicacin a escala

de "laboratorio". Pero tambin se necesita comprobar la respuesta de la aplicacin en

situaciones reales, e incluso, en situaciones de sobrecarga, tanto a escala de rendimiento como

de descontrol de datos.

Por ejemplo, una aplicacin lenta puede ser poco operativa y no til para el usuario.

Despus de las pruebas de carga, se encuentran las pruebas de aceptacin. Estas pruebas las

realiza el cliente o usuario final de la aplicacin desarrollada. Son bsicamente pruebas

funcionales, sobre el sistema completo, y buscan una cobertura de la especificacin de

requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, ya que

sera impresentable de cara al cliente, sino una vez pasadas todas las pruebas anteriores por

parte del desarrollador o el equipo de test.

Los programadores suelen obtener sorpresas en las pruebas de aceptacin, ya que es la

primera vez que se encuentran con el programa finalizado.

La objetivo de la prueba de aceptacin es obtener la aprobacin del cliente sobre la calidad de

funcionamiento del sistema desarrollado y probado.

La experiencia demuestra que, an despus del proceso ms cuidadoso de pruebas por parte

del desarrollador y el equipo de trabajo, quedan una serie de errores que slo aparecen

cuando el cliente pone en funcionamiento la aplicacin o el sistema desarrollado.

Sea como sea, el cliente siempre tiene la razn. Por este motivo, muchos desarrolla-dores

ejercitan unas tcnicas denominadas pruebas alfa y pruebas beta.

Las pruebas alfa consisten a invitar al cliente que venga en el entorno de desarrollo a probar el

sistema. Se trabaja en un entorno controlado y el cliente siempre tiene un experto a mano para

ayudarle a usar el sistema y para analizar los resultados.

Las pruebas beta vienen despus de las pruebas alfa, y se desarrollan en el entorno del cliente,

un entorno que est fuera de control para el desarrollador y el equipo de trabajo. Aqu el

cliente se queda solo con el producto y trata de encontrar los errores, de los que informar el

desarrollador.

Las pruebas alfa y beta son habituales en productos que se vendern a muchos clientes o que

utilizarn muchos usuarios. Algunos de los compradores potenciales se prestan a estas

pruebas, ya sea para ir entrenando a su personal con tiempo, ya sea en compensacin de

alguna ventaja econmica (mejor precio sobre el producto acabado, derecho a mantenimiento

gratuito, a nuevas versiones ...).

La experiencia muestra que estas prcticas son muy eficaces. En un entorno de desarrollo de

software tienen sentido cuando la aplicacin o sistema para desarrollar el usar un gran

nmero de usuarios finales (empresas grandes con diferentes departamentos que tendrn que

utilizar esta nueva herramienta).

Pruebas de sistema y de seguridad

Las pruebas de sistema son aquellas pruebas que se llevarn a cabo una vez finalizadas las

pruebas unitarias (cada mdulo por separado), las pruebas de integracin de los mdulos, las

pruebas de carga y las pruebas de aceptacin por parte del usuario.

Temporalmente, se encuentran en una situacin en la que el usuario ha podido verificar la

aplicacin desarrollada llevando a cabo las pruebas de aceptacin. Posteriormente, la

aplicacin se ha integrado en su nuevo entorno de trabajo.

Las pruebas de sistema servirn para validar la aplicacin una vez sta haya sido integrada con

el resto del sistema del usuario. Aunque la aplicacin ya haya sido validada de forma

independiente, a las pruebas de sistema se llevar a cabo una segunda validacin con la

aplicacin ya integrada en su entorno de trabajo real.

A continuacin se enumeran algunos tipos de pruebas para desarrollar durante las pruebas del

sistema:

Pruebas de rendimiento: valorarn los tiempos de respuesta de la nueva

aplicacin, el espacio que ocupar en el disco, el flujo de datos que generar a travs

de un canal de comunicacin.

Pruebas de resistencia: valorarn la resistencia de la aplicacin para

determinadas situaciones del sistema.

Pruebas de robustez: valorarn la capacidad de la aplicacin para soportar

varias entradas no correctas.

Pruebas de seguridad: ayudarn determinar los niveles de permisos de los

usuarios, las operaciones que podrn llevarse a cabo y las de acceso al sistema ya los

datos.

Pruebas de usabilidad: determinarn la calidad de la experiencia de un usuario

en la manera de interactuar con el sistema.

Pruebas de instalacinInstalacin: indicarn las operaciones de arranque y de

actualizacin de los programas.

Las pruebas de sistema aglutinan muchas otras pruebas que tendrn varios objetivos:

Observar si la aplicacin hace las funciones que tiene que hacer y si el nuevo

sistema se comporta como debera hacerlo.

Observar los tiempos de respuesta para las diferentes pruebas de rendimiento,

volumen y sobrecarga.

Observar la disponibilidad de los datos en el momento de recuperacin de un

error (a la vez que la correccin).

Observar la usabilidad.

Observar la instalacin (asistentes, operadores de arranque de la aplicacin,

actualizaciones del software ...).

Observar el entorno una vez la aplicacin est funcionando a pleno

rendimiento (comunicaciones, interacciones con otros sistemas ...).

Observar el funcionamiento de todo el sistema a partir de las pruebas globales

realizadas.

Observar la seguridad (control de acceso e intrusiones ...).

Las pruebas a escala global del sistema se han ido produciendo a medida que se tenan

funcionalidades perfectamente acabadas. Es el caso, por ejemplo, de probar el funcionamiento

correcto del desarrollo de una partida en uno de los tres juegos, o la navegacin correcta por

las diferentes pantallas de los mens.

Las pruebas de validacin permiten comprobar si, efectivamente, se cumplen los requisitos

propuestos por nuestro sistema.

Pruebas de regresin y pruebas de humo

Las pruebas de regresin buscan detectar posibles nuevos errores o problemas que puedan

surgir en haber introducido cambios o mejoras en el software.

Estos cambios pueden haber sido introducidos para solucionar algn problema detectado en la

revisin del software a raz de una prueba unitaria, de integracin o de sistema. Estos cambios

pueden solucionar un problema pero provocar a otros, sin haberlo previsto, en otros lugares

del software. Es por esta razn que hay que llevar a cabo las pruebas de regresin al finalizar el

resto de pruebas.

Un control no conveniente de los cambios de versiones, o una falta de consideracin hacia

otros mdulos o partes del software, pueden ser causas de los problemas para detectar en las

pruebas de regresin.

Se puede automatizar la deteccin de este tipo de errores con la ayuda de herramientas

especficas. La automatizacin es complementaria al resto de pruebas, pero facilitar la

repetibilidad. El problema que se puede derivar de la automatizacin de las pruebas de

regresin es que pedirn un mantenimiento complejo.

Las pruebas "De humo" se utilizan para describir la validacin de los cambios de cdigo en el

software, antes de que los cambios en el cdigo se registren en la documentacin del proyecto.

Se acostumbra llevar a cabo una revisin del cdigo antes de ejecutar las pruebas de humo.

Esta revisin del cdigo se har, sobre todo, en cuanto a los cambios que se hayan producido

en el cdigo.

1.3.3 Ejecucin de las pruebas

Despus de la planificacin de los procedimientos de pruebas y del diseo de los casos de

pruebas, el siguiente paso ser el proceso de ejecucin. Este proceso est representado en el

diagrama de flujo de la figura 01.18.

La ejecucin de las pruebas supondr seguir los siguientes pasos:

1. Ejecucin de las pruebas.

2. Comprobacin de si se ha producido algn error en la ejecucin de las pruebas.

3. Si no ha habido ningn error:

Se verifica la finalizacin de las pruebas.

Se valida si se necesitan pruebas adicionales.

Si se necesitan pruebas adicionales, hay que validar que no existan

condiciones anormales. Si hay condiciones anormales, se finaliza el proceso de

pruebas haciendo una evaluacin del mismo proceso, si no, habr que depurar

las pruebas.

Si no se necesitan pruebas adicionales, se llevar a cabo una

finalizacin del proceso de pruebas haciendo una evaluacin del mismo

proceso.

4. En el caso de haber encontrado errores en la ejecucin

de las pruebas, habr que ver si estos errores han sido debidos a:

Un defecto del software. En este caso, la

ejecucin de las pruebas ha cumplido su objetivo y habr

depurar el cdigo de programacin, localizar el o los

errores y solucionarlo para volver al punto inicial, en la

que se volvern a ejecutar las pruebas y se volver a

validar si el cambio efectuado ha sido exitoso.

Un defecto del diseo de las pruebas. En este

caso, habr que revisar las pruebas que se han

ejecutado, depurndose las, localizando el o los errores y solucionarlo, por tener unas

pruebas correctas, sin errores, listas para volver al punto inicial y volver a ejecutarlas.

Figura 1:18. Ejecucin de las pruebas

Pruebas "De humo"

El cabo pruebas de humo surge a

partir de la fabricacin de

hardware. Si despus de reparar

un componente de hardware,

este "no echa humo", es que

funcionar correctamente.

Una ejecucin de las pruebas exitosa no es aquella que encuentra errores a toda costa ni

aquella que slo evala dos o tres posibilidades, sino que es aquella que cumple lo planificado

en el plan de pruebas y que garantiza que lo diseado sea el que se valide.

1.3.4 Finalizacin: evaluacin y anlisis de errores

El ltimo paso de los procedimientos de pruebas ser la finalizacin del proceso. Para poder

darlo por cerrado de forma exitosa, se deber efectuar una evaluacin y un anlisis de los

errores localizados, tratados, corregidos y reevaluados.

Si no se puede dar por finalizado el proceso de pruebas, ser necesario llevar a cabo una

replanificacin del proceso de pruebas para establecer nuevas depuraciones y nuevas pruebas,

planificando y diseando de nuevo.

En el caso de tener que rehacer los procedimientos de pruebas,es muy importante la creacin

de nuevos casos de pruebas y no la readaptacin de los ya existentes. Si se crean nuevos casos

de pruebas, estar rediseando los procedimientos de pruebas sobre el mismo cdigo fuente,

si se intentan readaptar los ya existentes o modificar el cdigo, se corre el riesgo de hacer que

el cdigo fuente sea el que se est adaptando a los casos de pruebas.

Finalmente, es conveniente escribir un informe que ayude a almacenar la experiencia que se

ha recogido a lo largo del procedimiento de pruebas. Esta informacin ser muy importante

para futuros proyectos, ya que ayudar a no volver a repetir los mismos errores detectados. El

informe deber dar respuesta a tems como los que se indican a continuacin:

Nmero de casos de prueba generados.

Nmero de errores detectados en cada fase del proyecto.

Tiempo y recursos dedicados a los procedimientos de pruebas.

Tipo de pruebas llevadas a cabo.

Tipo de pruebas que ms errores han detectado.

Nivel de calidad del software.

Mdulos donde ms errores se han detectado.

Errores que han llegado hasta los usuarios finales.

Nmero de casos de prueba errneos detectados.

1.3.5 Depuracin del cdigo fuente

Las pruebas que se efectan sobre todo un proyecto informtico con todos los procesos

involucrados (planificacin, diseo, ejecucin y evaluacin) ayudarn a la deteccin y

correccin de errores, intentando encontrar a la mayor brevedad posible en el desarrollo del

proyecto . Una tcnica muy importante para la ejecucin de las pruebas y, en general, para los

programadores, es la depuracin del cdigo fuente.

La depuracin del cdigo fuente consiste a ir ejecutando paso a paso el cdigo fuente,

observando los estados intermedios de las variables y los datos implicados para facilitar la

correccin de errores.

Los procedimientos que estn vinculados a la depuracin del cdigo fuente son:

Identificar la casustica para poder reproducir el error.

Diagnosticar el problema.

Solucionar el error atacando el problema.

Verificar la correccin del error y verificar que no se han introducido nuevos

errores en el resto del software.

La depuracin del cdigo es una herramienta muy til si se sabe localizar el mdulo o la parte

del cdigo fuente donde se encuentra un determinado error. Si el error es difcil de reproducir

ser muy complicado encontrar una solucin para solucionarlo. Por ello, acotando-lo dentro

del cdigo, se puede ir localizando, haciendo pruebas para llegar a las circunstancias que lo

reproducen.

Habr que tener cuidado con las soluciones aplicadas cuando se usa la tcnica de la depuracin

del cdigo. Muchas veces una modificacin en el cdigo para solucionar un problema puede

generar otro error que est relacionado o que no tenga nada que ver. Habr que volver a

confirmar la correcta ejecucin del cdigo una vez finalizada la correccin.

La depuracin de cdigo permite la creacin de un punto en el cdigo fuente hasta el que el

software ser ejecutado de forma directa. Cuando la ejecucin haya llegado a este punto de

ruptura, se podr avanzar en la ejecucin del cdigo paso a paso hasta encontrar el error que

se busca.

Otra forma de llevar a cabo la depuracin de cdigo es ir hacia atrs, desde el punto del error,

hasta encontrar el causante. Esta tctica se utiliza en casos ms complejos y no es tan habitual,

pero ser muy til en el caso de no tener detectada la ubicacin del error, que puede

encontrarse oculto en alguna parte del cdigo fuente. En estos casos, a partir del lugar donde

se genera el error, se llevar a cabo un recorrido hacia atrs, yendo paso a paso en sentido

inverso.

Una herramienta que ayuda a la depuracin del cdigo fuente es la utilizacin de ficheros

llamados registros (logs). Estos ficheros, habitualmente de texto, registran toda la informacin

vinculada a la ejecucin de un software con el objetivo de que el programador pueda hacer

una revisin paso a paso de cmo ha evolucionado esta ejecucin y localizar errores o malos

funcionamientos.

La depuracin del cdigo es bastante til tambin en la ejecucin de las pruebas de

integracin, de sistema y de aceptacin.

Eclipse proporciona un entorno de depuracin que facilita la deteccin de errores, permitiendo

seguir el cdigo paso a paso y consultar los valores que van tomando los datos.

En la figura 1.19 se muestra el entorno de trabajo de la herramienta Eclipse a la hora de llevar a

cabo las acciones de depuracin.

Figura 1:19. Eclipse: perspectiva de depuracin

1.4 Herramientas para la realizacin de pruebas Las herramientas informticas para la realizacin de pruebas ayudarn mucho poder

automatizar la tarea de ejecutar las pruebas y algunos de los otros procesos que hay que hacer

para implementarlas (planificacin, diseo ...). Tal como sucede con las herramientas

especficas para el desarrollo de software, tambin existen herramientas especficas para la

ayuda a los procedimientos de pruebas.

Esto s, como todo, el uso de estas herramientas tendr algunos puntos positivos, pero tambin

conllevar algunos puntos dbiles.

1.4.1 Beneficios y problemas del uso de herramientas de pruebas

LA ayuda que aportan las herramientas para la realizacin de pruebas es la de automatizar una

tarea que muchas veces es muy repetitiva y puede llegar a reclamar mucho tiempo a los

implicados en caso de hacerlo de forma manual. Adems, a medida que se van desarrollando

las pruebas de forma manual, con el paso del tiempo, hay ms riesgo de que se produzcan

errores humanos por parte de los desarrolladores o los verificadores.

La utilizacin de una herramienta que automatice las pruebas ofrece la posibilidad de generar

los casos de pruebas, ejecutarlos y comparar los resultados obtenidos con los resultados

esperados. Muchas veces, tantos datos tan parecidos favorecen la aparicin de errores, que

con las herramientas informticas se pueden minimizar. Adems, son especialmente tiles para

confirmar que un error se ha solucionado.

Las herramientas de ayuda a la elaboracin de pruebas ofrecen, tambin como puntos fuertes,

una contraposicin a la repeticin de los errores a la hora de desarrollar las pruebas. Si un

mismo programador ha desarrollado el cdigo fuente y es el encargado de generar los casos de

prueba podr repetir, inconscientemente, los errores que ha cometido una vez. Si se usa un

software para desarrollar un proyecto, y se quieren generar las pruebas con el mismo software,

este mismo software las automatizar de tal manera que no se repitan los posibles errores de

programacin. Esta consistencia y garanta a la hora de llevar a cabo las pruebas es ms difcil

de ser mostrada por un ser humano.

Otro punto fuerte de las herramientas de automatizacin de las pruebas son las

funcionalidades que ofrecen a modo de resumen y que permiten tener ms informacin tanto

de las pruebas como del cdigo desarrollado. Ser igual de importante la correcta realizacin

de las pruebas como la informacin que se puede extraer y la forma de acceder. Una

herramienta de gestin de pruebas puede ofrecer informes estadsticos sobre los resultados de

las pruebas, sobre los diferentes mdulos evaluados, sobre los resultados, sobre las partes del

cdigo fuente ms fiables y las que no ... Toda esta informacin, presentada de una forma

adecuada, facilitar la toma de decisiones y la resolucin de problemas.

Como puntos dbiles en la utilizacin de herramientas de automatizacin de las pruebas se

pueden encontrar:

Tiempo que hay que dedicar a aprender a utilizar correctamente este

programa-rio. A veces es necesario dedicar tanto tiempo a conocer a conciencia una

herramienta informtica como el que se dedicara a efectuar las pruebas de forma

manual. Cada aplicacin informtica tiene sus caractersticas y sus especificaciones a la

hora de ser utilizada. Se debern conocer bien para sacar el mximo provecho.

Si no hay una buena configuracin y una buena seleccin de las pruebas, los

resultados obtenidos de las herramientas en la realizacin de las pruebas tampoco

sern fiables y se podran dar por buenos unos resultados que no lo son. Las

aplicaciones son fiables si se saben utilizar correctamente.

Dentro del proyecto, ser recomendable tener una persona que se dedique de

forma exclusiva a esta tarea.

1.4.2 Algunas herramientas de pruebas de software

Las herramientas de pruebas del software se pueden clasificar segn muchos criterios: en

funcin del o de los lenguajes de programacin a que se apoya, en funcin de si son privativos

o de cdigo abierto, o en funcin, por ejemplo, del tipo de pruebas que permiten llevar a cabo.

Se debe considerar que la gran mayora de los entornos integrados de desarrollo llevan

integradas herramientas que permiten la depuracin del cdigo fuente. Algunas de ellas

tambin permiten el desarrollo de pruebas o el hecho de aadir algn mdulo que lo permita.

A continuacin se enumeran algunas herramientas que permiten el desarrollo de pruebas en

funcin del tipo de pruebas:

Pruebas unitarias:

JUnit. Automatiza las pruebas unitarias y de integracin.

Provee clases y mtodos que facilitan la tarea de efectuar pruebas en el

sistema para asegurar la consistencia y funcionalidad del software

desarrollado.

Pruebas estticas de cdigo:

PMD. Puede ser integrado a diversas herramientas: JDeveloper,

Eclipse, jEdit, etc. Permite encontrar en el cdigo errores en el manejo

de excepciones, cdigo muerto, cdigo sin optimizar, cdigo duplicado

...

FindBugs. Puede integrarse Eclipse. Efecta un escaneo de

cdigo mediante el cual encuentra errores comunes, malas prcticas de

programacin, cdigo vulnerable, rendimiento, seguridad ...

YASCA. Permite encontrar vulnerabilidades de seguridad,

calidad en el cdigo, rendimiento ... Aprovecha la funcionalidad de los

conectores FindBugs, PMD y Jlint.

Pruebas de rendimiento:

JMeter. Permite efectuar pruebas de rendimiento, de estrs,

de carga y de volumen, sobre recursos estticos o dinmicos.

OpenSTA. Permite captar las peticiones del usuario generadas

en un navegador web, luego guardarlas, y poder editar para su

posterior uso.

WEbLoad.permite llevar a cabo pruebas de rendimiento, a

travs de un entorno grfico en el que se pueden desarrollar, grabar y

editar script de pruebas.

Grinder.es un framework (Entorno de trabajo) escrito en Java,

con el que se pueden efectuar pruebas de rendimiento, por medio

descript escritos en lenguaje Jython. Permite grabar las peticiones del

cliente sobre un navegador web para ser luego reproducido.

Pruebas de aceptacin:

Fitness. Permite comparar lo que debe hacer el software con el que

realmente hace. Se pueden efectuar pruebas de aceptacin y pruebas de reglas

de negocio.

Avignon. Permite los usuarios expresar pruebas de aceptacin de una

forma no ambigua antes de que comience el desarrollo. Trabaja en conjunto

con JUnit, HTTPUnit ...

2. Herramientas para el control y documentacin de software

Qu es ms importante, dedicar el menor tiempo posible en el desarrollo de una aplicacin

informtica (y ahorrarnos todo el coste posible de un programador), o bien desarrollar la

misma aplicacin con un cdigo fuente mucho ms optimizado y preparado para futuros

cambios (habiendo dedicado ms esfuerzo)?

En el proceso de desarrollo de software es muy importante tener en cuenta ciertas directrices

muy recomendables que, por otra parte, muchas veces no se siguen por falta de cultura y por

la idea equivocada de que el hecho de seguirlas elevar los costos a nivel de tiempo.

Cunto cuesta tener un software desarrollado de forma ptima? Si un software hace lo que

tiene que hacer, es eficaz y es eficiente, por qu es necesario que sea ptimo? Adems, si el

desarrollo de un software hecho con prisas puede ahorrar tiempo de programadores, y el

tiempo siempre es valorable en dinero, por qu se ha de invertir en desarrollar de forma

ptima?

Las razones son muchas. Siempre costar lo mismo hacer las cosas mal hechas que hacerlas

bien hechas, si te has acostumbrado a hacerlas bien hechas desde un principio y lo aprendido

as. En un futuro, el mantenimiento y las posibles ampliaciones del software sern mucho ms

costosas si has intentado ahorrar en tiempo antes.

Qu significa programar de forma ptima? Hay muchas cosas a tener en cuenta y se pueden

encontrar muchos consejos al respecto.

2.1 Refactorizacin

Al desarrollar una aplicacin hay que tener muy presentes algunos aspectos del cdigo de

programacin que se ir implementando. Hay pequeos aspectos que permitirn que este

cdigo sea considerado ms ptimo o que facilitarn su mantenimiento. Por ejemplo, uno de

estos aspectos ser la utilizacin de constantes. Si hay un valor que se usar varias veces a lo

largo de un determinado programa, es mejor utilizar una constante que contenga este valor, de

esta manera, si el valor cambia slo deber modificar la definicin de la constante y no habr

irlo buscando por todo el cdigo desarrollado ni recordar cuntas veces se ha utilizado.

A continuacin, se muestra un ejemplo muy sencillo para entender a qu se hace referencia

cuando se habla de optimizar el cdigo fuente:

1Class CalculCostos {

2 Public static double CostTreballadors (double NreTreballadors)

3 {

4 Return 1200 *NreTreballadors;

5 }

6}

En el cdigo anterior se muestra un ejemplo de cmo sera la codificacin de una clase que

tiene como funcin el clculo de los costes laborales totales de una empresa. Se puede ver que

el coste por trabajador no se encuentra en ninguna variable ni a ningn constante, sino que el

mtodo CostTreballadors devuelve el valor que ha recibido por parmetro ( r r

rs) por un nmero que considera el salario bruto por trabajador (en este caso

supuesto 1.200 euros). Probablemente, este importe se utilizar adems clases durante el

cdigo de programacin desarrollado o, como mnimo, ms veces dentro de la misma clase.

Como quedara el cdigo una vez aplicada la refactorizacin? Se puede ver a continuacin:

1Class CalculCostos {

2 final double SALARI_BRUT = 1,200;

3 Public static double CostTreballadors (double NreTreballadors)

4 {

5 Return SALARI_BRUT * NreTreballadors;

6 }

7}

Este es un ejemplo de lo que se entiende por refactorizacin.

El trmino refactorizacin hace referencia los cambios efectuados en el cdigo de

programacin desarrollado, sin implicar ningn cambio en los resultados de su ejecucin. Es

decir, se transforma el cdigo fuente manteniendo intacto su comportamiento, aplicando los

cambios slo en la forma de programar o en la estructura del cdigo fuente, buscando su

optimizacin.

El trmino refactorizacin fue utilizado por primera vez por William F. Opdyke a su tesis

doctoral, en 1992, en la Universidad

de Illinois.

A la figura 2.1 se puede ver un ejemplo de lo que se quiere expresar. Cul de las

dos casas facilita ms la vida de sus inquilinos? Si hubiera que desarrollar una aplicacin

informtica, a cul de las dos casas debera parecerse ms a la de la izquierda o la de la

derecha?

Figura 2.1. Diseo de una casa

Posiblemente las dos casas cumplen las especificaciones iniciales, edificio en el que se pueda

vivir, pero parece que la primera casa ser ms confortable y ms ptima.

El trmino refactorizacin proviene del trmino refactoritzar (refactoring). Este trmino

deviene de su similitud con el concepto de factorizacin de los nmeros o los polinomios. Es lo

mismo tener 12 que tener 3 4, pero, en el segundo caso, el trmino 12 est dividido en sus

factores (aunque se podra factorizar ms y llegar al 3 22). Otro ejemplo: el polinomio de

segundo grado x2-1 es el mismo que el resultado del producto (x+ 1) (x- 1), pero en el segundo

caso se ha dividido en factores. A la hora de simplificar o hacer operaciones, ser mucho ms

sencillo el trabajo con el segundo caso (con los trminos ya factoritzats) que con el primero.

Con la factorizacin aparecen unos trminos, unos valores, que inicialmente se encuentran

ocultos, aunque forman parte del concepto inicial.

En el caso de la programacin sucede una situacin muy similar. Si bien el cdigo que se

desarrolla no est factorizado, es decir, no se ven a simple vista los factores internos, porque

son estructuras que aparentemente se encuentran escondidas, cuando se lleva a cabo una

refactorizacin del cdigo fuente s se pueden ver.

2.1.1 Ventajas y limitaciones de la refactorizacin

La utilizacin de la refactorizacin puede aportar algunas ventajas a los desarrolladores de

software, pero hay que tener en cuenta que tiene limitaciones que hay que conocer antes de

tomar la decisin de utilizarla.

Ventajas de la refactorizacin

Hay muchas ventajas en la utilizacin de la refactorizacin, aunque tambin hay inconvenientes

y algunas limitaciones. Por qu los programadores dedican tiempo a la refactorizacin del

cdigo fuente? Una de las respuestas a esta pregunta es el aumento de la calidad del cdigo

fuente. Un cdigo fuente sobre el que se han utilizado tcnicas de refactorizacin se

mantendr en un estado mejor que un cdigo fuente sobre el que no se hayan aplicado. A

medida que un cdigo fuente original se ha ido modificando, ampliando o manteniendo, habr

sufrido modificaciones en la estructura bsica sobre la que se dise, y es cada vez ms difcil

efectuar evolutivos y aumenta la probabilidad de generar errores.

Algunas de las ventajas o razones para utilizar la tcnica de refactorizacin del cdigo fuente

son:

Prevencin de la aparicin de problemas habituales a partir de los cambios provocados

por los mantenimientos de las aplicaciones.

Ayuda a aumentar la simplicidad del diseo.

Mayor entendimiento de las estructuras de programacin.

Deteccin ms sencilla de errores.

Permite agilizar la programacin.

Genera satisfaccin en los desarrolladores.

A continuacin, se desarrollan algunos de estos puntos fuertes de la utilizacin de la

refactorizacin:

Deteccin y prevencin ms sencilla de errores.La refactorizacin mejora la robustez

del cdigo fuente desarrollado, haciendo que sea ms sencillo encontrar errores en el cdigo o

encontrar partes del cdigo que sean ms propensas a tener o provocar errores en el conjunto

del software. A partir de la utilizacin de casos de prueba adecuados, se podr mejorar mucho

el cdigo fuente.

Prevencin de problemas por culpa de los mantenimientos del software.Con el tiempo,

suelen surgir problemas a medida que se va aplicando un mantenimiento evolutivo o un

mantenimiento correctivo de las aplicaciones informticas. Algunos ejemplos de estos

problemas pueden ser que el cdigo fuente se vuelva ms complejo de entender de lo que

sera necesario o que haya duplicidad de cdigo, debido a que, muchas veces, son personas

diferentes las que han desarrollado el cdigo de las que estn llevando a cabo el

mantenimiento.

Comprensin del cdigo fuente y simplicidad del diseo. Volviendo a la situacin en la

que un equipo de programacin puede estar compuesto por un nmero determinado de

personas diferentes o que el departamento de mantenimiento de una empresa es diferente en

el equipo de desarrollo de nuevos proyectos, es muy importante que el cdigo fuente sea muy

fcil de entender y que el diseo de la solucin haya sido creado con una simplicidad

considerable. Es necesario que el diseo se lleve a cabo teniendo en cuenta que se har una

posterior refactorizacin, es decir, teniendo presentes posibles necesidades futuras de la

aplicacin que se est creando. Esta tarea no es nada sencilla, pero con un buen y exhaustivo

anlisis, por medio de muchas conversaciones con los usuarios finales, se podrn llegar a

vislumbrar estas necesidades futuras.

Programacin ms rpida. Precisamente, si el cdigo se comprende de una forma

rpida y sencilla, la evolucin de la programacin ser mucho ms rpida y eficaz. El diseo

llevado a cabo en la fase anterior tambin ser decisivo en el hecho de que la programacin

sea ms gil.

Limitaciones de la refactorizacin

En cambio, se pueden encontrar varias razones para no considerar adecuada su utilizacin, ya

sea por sus limitaciones o por las posibles problemticas que pueden surgir:

Personal poco preparado para utilizar las tcnicas de la refactorizacin.

Exceso de obsesin para conseguir el mejor cdigo fuente.

Excesiva dedicacin de tiempo a la refactorizacin, provocando efectos negativos.

Repercusiones en el resto del software y del equipo de desarrolladores cuando uno de

ellos aplica tcnicas de refactorizacin.

Posibles problemas de comunicacin provocados por el punto anterior.

Limitaciones debidas a las bases de datos, interfaces grficas ...

Algunos de estos puntos dbiles relacionados con la utilizacin de la refactorizacin quedan

desarrollados a continuacin:

Dedicacin de tiempo. Una actitud obsesiva con la refactorizacin podr llevar a un

efecto contrario al que se busca: dedicar mucho ms tiempo del que sera necesario la creacin

de cdigo y aumentar la complejidad del diseo y de la programacin innecesariamente.

Afectar o generar problemas al resto del equipo de programacin. Una refactorizacin

de un programador puede generar problemas a otros componentes del equipo de trabajo, en

funcin de donde se haya llevado a cabo esta refactorizacin. Si slo afecta a una clase oa

algunos de sus mtodos, la refactorizacin ser imperceptible al resto de sus compaeros. Pero

cuando afecta a varias clases, podr alterar de otro cdigo fuente que haya sido desarrollado o

est desarrollando por parte de otros compaeros. Este problema slo se puede solucionar con

una buena comunicacin entre los componentes del equipo de trabajo o con una

refactorizacin sincronizada desde los responsables del proyecto, manteniendo informados a

los afectados.

Limitaciones debidas a las bases de datos.La refactorizacin tiene algunas limitaciones

o reas conflictivas, como las bases de datos o las interfaces grficas. En el caso de las bases de

datos, es un problema el hecho de que los programas que se desarrollan actualmente estn

tan atados a sus estructuras. En el caso de haber modificaciones relacionadas con la

refactorizacin en el diseo de la base de datos vinculada a una aplicacin, habra que llevar a

cabo muchas acciones que complicaran esta actuacin: habra que ir a la base de datos,

efectuar los cambios estructurales adecuados , hacer una migracin de los datos al nuevo

sistema y adaptar de nuevo todo aquello de la aplicacin relacionado con los datos

(formularios, informes ...).

Interfaces grficas. Una segunda limitacin se encuentra con las interfaces grficas de

usuario. Las nuevas tcnicas de programacin han facilitado la independencia entre los

distintos mdulos que componen las aplicaciones. De esta manera, se podr modificar el

contenido del cdigo fuente sin tener que hacer modificaciones en el resto de mdulos, como

por ejemplo, en las interfaces. El problema con la refactorizacin vinculado con las interfaces

grficas radica en el hecho de que si esta interfaz ha sido publicada en muchos usuarios

clientes o si no se tiene accesibilidad al cdigo que la genera, ser prcticamente imposible

actuar sobre ella.

La refactorizacin se considera un aspecto muy importante para el desarrollo de aplicaciones

mediante programacin extrema.

2.1.2 Patrones de refactorizacin ms usuales

El patrones se pueden encontrar en todas las versiones de Eclipse para los diferentes sistemas

operativos (Windows, Linux y

MacOS).

Los patrones, en un contexto de programacin, ofrecen una solucin durante el proceso de

desarrollo de software a un tipo de problema o necesidad estndar que puede darse en

diferentes contextos. El patrn dar una resolucin a este problema, que ya ha sido aceptada

como solucin buena, y que ya ha sido bautizada con un nombre.

Por Por otra parte, ya ha quedado definida la refactorizacin como adaptaciones del cdigo

fuente sin que ello provoque cambios en las operaciones del software. Si se unen estos dos

conceptos se pueden encontrar