software: técnicas calidad del de prevención, detección y …uoc.gitlab.io/2015/desarrollo...

Calidad delsoftware: técnicasde prevención,detección ycorrección dedefectos Xavier Escudero Sabadell PID_00178932

© FUOC • PID_00178932 Calidad del software: técnicas de prevención, detección y corrección...

Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico,químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escritade los titulares del copyright.


Índice

Introducción............................................................................................... 7

Objetivos....................................................................................................... 8

1. Técnicas de detección de fallos. Las pruebas.............................. 9

1.1. Principios de las pruebas ............................................................ 9

1.2. Niveles de prueba ........................................................................ 11

1.2.1. Pruebas unitarias o de componente .............................. 13

1.2.2. Pruebas de integración .................................................. 14

1.2.3. Pruebas de sistema ......................................................... 17

1.2.4. Pruebas de aceptación ................................................... 17

1.3. Tipos de prueba ........................................................................... 18

1.3.1. Tipo de pruebas según características de calidad ........... 18

1.3.2. Pruebas de confirmación y regresión ............................ 20

1.3.3. Pruebas de humo ........................................................... 20

1.3.4. Pruebas manuales y automatizadas ............................... 21

1.4. Tipos de entornos de prueba ...................................................... 21

1.5. El proceso de pruebas. Actividades y entregables ....................... 22

1.5.1. Planificación y control .................................................. 23

1.5.2. Análisis y diseño ............................................................ 24

1.5.3. Implementación ............................................................. 27

1.5.4. Ejecución ........................................................................ 28

1.5.5. Evaluación del criterio de salida e informe de

resumen .......................................................................... 29

1.5.6. Cierre .............................................................................. 29

1.6. Técnicas de diseño de prueba dinámicas .................................... 29

1.6.1. Técnicas dinámicas basadas en la especificación ........... 31

1.6.2. Técnicas dinámicas basadas en la estructura ................. 35

1.6.3. Técnicas dinámicas basadas en la experiencia ............... 37

1.6.4. Técnicas dinámicas basadas en defectos ....................... 38

2. Técnicas de detección de defectos. Las revisiones y el

análisis estático.................................................................................. 40

2.1. Revisiones .................................................................................... 40

2.1.1. Tipos de revisiones. Roles y responsabilidades .............. 40

2.1.2. El proceso de revisión ................................................... 41

2.1.3. Listas de comprobación ................................................. 43

2.2. Análisis estático ........................................................................... 43

2.2.1. Análisis de la estructura del código ............................... 43

2.2.2. Cumplimiento de estándares de programación ............ 44

2.2.3. Cálculo de métricas de código ...................................... 44


3. Técnicas de localización y corrección de defectos.................... 45

3.1. La depuración .............................................................................. 45

3.1.1. Reproducción del fallo .................................................. 45

3.1.2. Diagnóstico .................................................................... 46

3.1.3. Corrección ...................................................................... 47

3.1.4. Gestión del conocimiento y cierre ................................ 48

3.2. Bitácora ........................................................................................ 49

3.3. Refactoring del código .................................................................. 54

4. Técnicas de prevención de defectos.............................................. 57

4.1. Análisis de causa raíz .................................................................. 57

4.2. Educación y formación ............................................................... 58

4.3. Guías y estándares de programación .......................................... 59

4.4. Validación de los datos ............................................................... 60

4.4.1. Diseño por contrato ...................................................... 61

4.5. Desarrollo guiado por pruebas .................................................... 62

4.6. Reutilización ................................................................................ 63

5. Técnicas de tolerancia a fallos....................................................... 65

5.1. Detección del fallo ...................................................................... 65

5.2. Generación de la excepción ........................................................ 66

5.3. Gestión de la excepción .............................................................. 68

5.4. Recuperación ............................................................................... 71

6. Herramientas....................................................................................... 73

6.1. Herramientas de gestión de las pruebas ..................................... 73

6.2. Herramientas de diseño y preparación de datos de las

pruebas ........................................................................................ 74

6.3. Herramientas para la ejecución de pruebas dinámicas ............... 75

6.3.1. Automatización de las pruebas ...................................... 76

6.3.2. Herramientas para la ejecución de pruebas unitarias

e integración .................................................................. 77

6.3.3. Herramientas para la ejecución de pruebas de

sistema ........................................................................... 77

6.4. Herramientas para la ejecución de pruebas estáticas .................. 80

6.4.1. Herramientas de revisión ............................................... 80

6.4.2. Herramientas de análisis estático de código .................. 80

6.5. Herramientas de soporte al desarrollo ........................................ 81

6.5.1. Herramientas de soporte a la programación ................. 81

6.5.2. Herramientas de depuración ......................................... 82

6.5.3. Herramientas de integración continua .......................... 83

6.5.4. Herramientas de gestión de la configuración ................ 83

Resumen....................................................................................................... 84

Actividades.................................................................................................. 85


Ejercicios de autoevaluación.................................................................. 86

Solucionario................................................................................................ 88

Glosario........................................................................................................ 92

Bibliografía................................................................................................. 94

© FUOC • PID_00178932 7 Calidad del software: técnicas de prevención, detección y corrección...

Introducción

Este módulo tiene como objetivo estudiar detalladamente las técnicas relacio-

nadas con la prevención, detección, corrección y gestión de los defectos del

software.

En primer lugar, estudiaremos cuáles son las pruebas clásicas, sus objetivos

y los diferentes tipos de prueba existentes, considerando las diferentes fases

y entregables que se producen en ellas. Analizaremos también qué son las

revisiones y el análisis estático y qué beneficios aportan respecto de las pruebas

clásicas.

Evaluaremos cuáles son las técnicas que nos pueden ayudar a localizar los de-

fectos y a corregirlos con técnicas como la depuración, la bitácora y el refacto-

ring del código.

A continuación estableceremos cuáles son los medios con los que podemos

prevenir los defectos, desde los de carácter formativo hasta la implantación

de medidas de definición de buenas prácticas y el uso de técnicas específicas,

como el diseño por contrato.

A pesar de las diferentes técnicas anteriores, veremos que los fallos son inevi-

tables, por lo que analizaremos qué medidas existen para protegernos de ellos,

principalmente con la gestión de excepciones.

Por último, revisaremos las diferentes tipologías de herramientas que nos pue-

den dar soporte para la ejecución de las técnicas que habremos revisado en

el módulo.


Objetivos

Los objetivos que los estudiantes tenéis que haber alcanzado una vez trabaja-

dos los contenidos de este módulo son:

1. Entender qué son las pruebas y diferenciar los niveles y tipos que se pueden

realizar.

2. Entender el objetivo de las revisiones, cuál es el proceso formal que se tiene

que seguir en ellas, y por qué es necesario que se realicen durante todo el

ciclo de vida.

3. Entender las diferentes técnicas de diseño que tenéis a vuestro alcance para

realizar las pruebas y revisiones, teniendo en cuenta las restricciones de

tiempo y la tipología de las características a probar.

4. Entender el proceso de localización de defectos y cómo se pueden usar el

mecanismo de bitácora y el refactoring del código para mejorar su calidad.

5. Identificar los mecanismos de prevención que podemos aplicar para evitar

defectos en la programación, reconociendo la importancia de establecer

unas guías y buenas prácticas, analizar de forma continua dónde se pro-

ducen más defectos y realizar acciones de validación en los datos.

6. Saber utilizar los mecanismos de gestión de excepciones para el tratamien-

to de fallos inevitables.

7. Conocer cuáles son las diferentes herramientas que podéis utilizar para

aplicar todas las técnicas.


1. Técnicas de detección de fallos. Las pruebas

Las pruebas1 de software son una estrategia de gestión del riesgo en la que se

valida que los requisitos se han cumplido y se buscan defectos. Las pruebas

tienen un carácter "destructivo" en el sentido de que se tienen que planificar

y diseñar para encontrar defectos y fallos en el software. Implica un cambio

de mentalidad respecto al que desarrolla, que trata de demostrar que lo que

ha construido funciona, y no al revés.

Las pruebas son el proceso de análisis de un elemento de software para

detectar la diferencia entre las condiciones existentes y las requeridas y

evaluar las características del elemento de software.

Sin embargo, el objetivo de las pruebas no es únicamente encontrar defec-

tos, sino también obtener confianza en el nivel de la calidad de un software,

comparando los resultados obtenidos no solo con los resultados especificados

(funcionalidad) sino también con los esperados (confianza, facilidad de man-

tenimiento, usabilidad, rendimiento, etc.).

Si bien en algunos modelos se consideran las pruebas únicamente como un

proceso de ejecución de software, dentro de ellas también tenemos que incluir

las técnicas de revisión (revisión de entregables, proceso, etc.) y las de análisis

estático (análisis de la calidad del código fuente...). En este módulo conside-

raremos que las pruebas incluyen tanto la verificación como la validación du-

rante todo el ciclo de vida, extendiendo el modelo clásico en el que las pruebas

se realizan solo después de la construcción.

1.1. Principios de las pruebas

Existen diferentes aspectos que determinan el éxito y eficacia de las pruebas:

1) Los probadores tienen que evaluar e interpretar de forma meticulosa los

resultados obtenidos en las pruebas. En caso de una mala interpretación de

resultados, se puede concluir que las pruebas han ido bien, cuando lo que

realmente ha habido ha sido un fallo, o que han ido mal, cuando realmente

no ha habido ningún fallo. Eso puede comportar grandes esfuerzos en la de-

tección de defectos que no existen o en la aparición de defectos posteriores,

no detectados por un mal análisis.

2) Los casos de prueba tienen que ser desarrollados tanto para condiciones

de entrada válidas como inválidas. Considerar únicamente valores de entrada

válidos en las pruebas para demostrar que el software funciona correctamente

(1)En inglés, el proceso de las prue-bas se llama testing.

Ved también

En el módulo "Calidad del soft-ware: gestión de la calidad ymétricas" se ve que las pruebasestán contenidas dentro delcontrol de la calidad.


es uno de los errores más comunes. Los usuarios pueden cometer en la entra-

da de datos errores de tipo tipográfico, de formato o de valores permitidos,

aunque el software aporte información detallada de los valores que pueden ser

entrados, y puede ocurrir que el software no realice las validaciones necesarias

y permita valores incorrectos.

3) Las pruebas pueden mostrar qué defectos están presentes, pero no pueden

asegurar que no hay defectos. Se reduce la probabilidad de defectos no descu-

biertos, pero aunque no se encuentre ningún defecto, no tenemos ninguna

seguridad de que no haya defectos por descubrir.

4) Probar todas las condiciones y combinaciones es imposible, excepto en los

casos simples. En lugar de probar exhaustivamente, más vale realizar un análi-

sis de riesgos y prioridades para establecer la estrategia y esfuerzos de las prue-

bas.

5) Las actividades de prueba se han de iniciar lo más pronto posible en el ciclo

de vida del desarrollo. Las actividades de pruebas realizadas en fases iniciales,

como las revisiones o el diseño de las pruebas, pueden encontrar defectos que

se podrán corregir con un coste menor que si se hubieran descubierto en fases

finales del desarrollo.

Ejemplo

Revisando el diseño de la arquitectura podríamos detectar que no se ha tenido en cuentala gestión de los usuarios.

6) La mayoría de los defectos están causados por un pequeño número de mó-

dulos o áreas (los de mayor complejidad, mal diseñados, desarrollados por un

programador no experimentado, etc.), por lo que es bueno invertir más tiem-

po en probar estas áreas para encontrar más defectos. Si, por ejemplo, tenemos

en un sistema dos componentes, A y B, en los que se han encontrado 25 y 50

defectos, respectivamente, la probabilidad de encontrar más defectos en A es

más alta que la de encontrarlos en B.

Podemos encontrar una analogía en el principio de Pareto, o regla del 80-20,

para indicar que el 80% de los problemas se encuentran ubicados en el 20%

de los módulos.

Principio de Pareto

Pareto fue un economista italiano que observó que el 20% de la población italiana estabaen posesión del 80% de la propiedad (riqueza). Esta regla ha sido aplicada en diferentescampos (económicos, políticos, etc.) y también en el mundo informático.

El principio de Pareto también tiene aplicación en los costes de desarrollo, donde, nor-malmente, el 80% del esfuerzo de desarrollo acaba produciendo el 20% de código, mien-tras que el 20% de esfuerzo restante produce el 80% de código.


7) Aunque realicemos pruebas para encontrar o prevenir determinados defec-

tos, hay otros que pueden crecer ocultos. Si no actualizamos los casos de prue-

ba, las pruebas serán cada vez menos efectivas. Un buen proceso de pruebas

requiere que se actualicen los casos de prueba y se creen nuevas pruebas para

detectar otros tipos de defectos.

Analogía

Los insectos que sobreviven al uso de un pesticida son más inmunes al veneno que losdemás insectos. En este caso, las compañías que crean los pesticidas tienen que trabajarcontinuamente para encontrar nuevos productos que puedan eliminar los insectos quehan sobrevivido a los anteriores pesticidas.

8) Para ser más eficaces, las pruebas tienen que ser realizadas por un equi-

po independiente. Casi ningún programador admitirá que el software que ha

desarrollado tiene defectos, y el exceso de familiaridad hace muy difícil que

identifique los defectos de lo que él mismo ha producido. El requisito de un

grupo independiente de pruebas puede ser implementado como una entidad

separada de la organización, o bien como un grupo interno en el desarrollo,

pero dedicado únicamente a las actividades de pruebas y con visión objetiva.

Como humanos que somos, a veces no somos capaces de ver lo que hemos hecho maly necesitamos el apoyo de alguien externo y no "viciado" que tenga una visión indepen-diente y fresca.

9) Las pruebas han de ser repetibles. Hay que diseñarlas y ejecutarlas siempre

bajo las mismas condiciones (equipamientos, entradas, acontecimientos...)

para poder asegurar que el defecto se ha corregido. Si cambian las condiciones,

no podremos asegurarlo.

1.2. Niveles de prueba

Las pruebas se pueden realizar en diferentes niveles, según que queramos pro-

bar de forma aislada un componente, la integración entre componentes o el

funcionamiento del sistema como un todo. Esta clasificación es la denomina-

da de niveles de prueba, y en ella podemos diferenciar:

1)�Pruebas�unitarias�o�de�componente. Tienen como objetivo probar cada

componente (módulo, clase...) de forma aislada del resto del sistema. Están

consideradas como una actividad dentro del proceso de construcción, y, por

lo tanto, las realiza el equipo de desarrollo.

2)�Pruebas�de�integración. Se prueban las interfaces entre componentes, di-

ferentes partes del sistema (entre un componente y el sistema operativo, por

ejemplo), o bien entre sistemas (entre un sistema de nóminas y un sistema

externo bancario, por ejemplo). Suele realizarlas el equipo de pruebas, aunque

en algunos casos también las efectúa el equipo de desarrollo.


3)�Pruebas�de�sistema. Tienen como objetivo encontrar defectos y validar que

el sistema cumple las especificaciones, comparando los resultados obtenidos

con los requisitos del sistema. Son realizadas por el equipo de pruebas.

4)�Pruebas�de�aceptación. Es el último nivel, en el que el cliente tiene que

validar que el desarrollo ha cumplido lo que se requería de él y no hay riesgos

en la puesta en marcha del aplicativo.

Cuanto mejor se haya realizado un nivel de pruebas, mayor será la eficiencia

de los siguientes niveles y menores defectos se encontrarán en ellos.

En todos los niveles se pueden validar requisitos tanto funcionales como no

funcionales. Así, por ejemplo, podemos comprobar una funcionalidad en un

componente o en el sistema y, también, el rendimiento del componente o del

sistema.


1.2.1. Pruebas unitarias o de componente

Una unidad es la pieza más pequeña que se puede probar. Si bien en un lengua-

je procedimental la unidad mínima a probar es una función o procedimiento,

en orientación a objetos existen dos posibilidades, considerar un método o

una clase.

Unidad mínima en orientación a objetos

En orientación a objetos no hay consenso sobre si la unidad mínima a probar tiene queser un método o una clase al completo, así que se puede utilizar cualquiera de las dosposibilidades y hacer combinaciones entre ellas.

Las pruebas unitarias son desarrolladas y ejecutadas por los propios programa-

dores. Eso tiene algunos inconvenientes:

• Un programador desarrolla los casos de prueba unitarios para que funcio-

nen, en lugar de crearlos para que fallen (contrasta con la filosofía de pro-

bar si funciona y el objetivo de un probador que quiere encontrar defec-

tos).

• Los defectos encontrados no son registrados por el programador, por lo

que no podemos aprender de ellos o prevenirlos.

IEEE 1008

El estándar IEEE 1008 descri-be aspectos relacionados conpruebas unitarias.

En Java existen librerías para la creación de pruebas unitarias, entre las que

destaca JUnit. JUnit permite crear nuestros casos de prueba a partir de las clases

TestCase y TestSuite. La primera permite definir un caso de prueba, mientras

que la segunda sirve para agrupar diferentes casos de prueba.

Un caso de prueba que herede de TestCase tiene que definir tres grupos de

métodos:

1)�testNombrePrueba. Para cada condición de prueba que queramos compro-

bar crearemos un método con el prefijo "test". Dentro de ella podemos utilizar

diferentes sentencias de JUnit para comprobar los resultados de la ejecución.

La más habitual es assertEquals (permite comparar si el resultado obtenido

es igual al valor esperado).

2)�setUp. El código incluido en el método setUp se ejecutará siempre una vez

para todos los métodos testNombrePrueba. Sirve para inicializar las varia-

bles usadas en ellos, por ejemplo para abrir una conexión a la base de datos,

inicializar un fichero, etc.

3)�tearDown. En este método tenemos que cerrar cualquiera de los recursos

que hayamos utilizado en los métodos testNombrePrueba, habitualmente

los que se crearon en el setUp.

Ved también

Veremos más en detalle quéson un caso de prueba y unacondición de prueba en elsubapartado 1.5 de este mó-dulo.


Ejemplo

Supongamos que en nuestro sistema VCV nos piden incluir una política de fidelizaciónpor la que los puntos obtenidos por cada reserva realizada se acumulen y se pueda obtenercon ellos descuentos en la compra de libros, entradas de cine, etc. Para el cálculo de lospuntos, nos indican que sigamos el siguiente algoritmo:

• Dar 0 puntos si el número de adultos reservado es 1;• 2 puntos si el número de adultos es de más de 1 y hasta 9;• 5 puntos de 10 adultos hasta 24;• 10 puntos si es superior a 24;• el programa no acepta más de 50.

Este se ha implementado en Java con el siguiente código:

public class GestorFidelizacion { public int calcularPuntos(int aNumAdultos){ int puntos = 0; if (aNumAdultos>=2 && aNumAdultos<10) { puntos = 2; } else if (aNumAdultos>=10 && aNumAdultos<25) { puntos = 5; } else if (aNumAdultos>=25) { puntos = 10; } return puntos; }}

Vemos por medio de JUnit cómo podemos verificar con un caso de prueba que la funcióncalcularPuntos devuelve un 5 si introducimos el valor 18.

importe junit.framework.TestCase;

public class GestorFidelizacionTestCase extends TestCase { GestorFidelizacion GestorFidelizacion; @Override protected void setUp() throws Exception { GestorFidelizacion = new GestorFidelizacion(); }

@Override protected void tearDown() throws Exception { GestorFidelizacion = null; } public void testCalculoPuntos() throws Exception { assertEquals("Se espera que los puntos sean 5", 5, GestorFidelizacion.calcularPuntos(18)); }}

En el método setUp inicializamos el objeto que usaremos en los diferentes casos de prue-ba. En la ejecución del caso de prueba testCalculoPuntos se verifica que llamandoal método calcularPuntos con el valor 18 el resultado es 5. Si en alguna ejecución elresultado real no es el esperado, JUnit nos lo indicará. Finalmente, una vez ejecutadostodos los casos de prueba, se ejecuta el método tearDown, en el que se libera el objetoGestorFidelizacion usado.

1.2.2. Pruebas de integración

Respecto de las pruebas de integración se han de tener en cuenta tanto los

niveles de integración como las estrategias de las pruebas.


Niveles de integración

Las pruebas de integración pueden ser realizadas dentro de un sistema o entre

sistemas, por lo que pueden clasificarse en:

• Pruebas�de�integración�entre�componentes. Se prueba la interacción en-

tre componentes de un sistema. Estas pruebas se realizan a continuación

de las pruebas de componente.

• Pruebas�de�integración�entre�sistemas. Se prueba la interacción entre sis-

temas independientes que son integrados entre sí. Se realizan a continua-

ción de las pruebas de sistema. Se aplican a casos en los que construimos

una aplicación que está formada por diferentes sistemas construidos por

distintos equipos.

Este nivel de pruebas y las pruebas de sistema las realizan grupos de profesio-

nales dedicados a las pruebas.

Estrategias de pruebas de integración

A menudo, las pruebas de integración no se pueden realizar de golpe, cuando

ya están desarrollados todos los módulos (componentes o sistemas de un sis-

tema), sino que se van realizando a medida que se van desarrollando y pro-

bando los módulos. Basándonos en eso podemos establecer diferentes estrate-

gias de integración.

El caso más extremo es esperar a que todos los módulos estén desarrollados

e integrados para realizar las pruebas de integración. A esta estrategia se la

llama big-bang o estrategia no incremental. En contraposición encontramos las

estrategias incrementales, en las que los módulos se van probando a medida

que se van desarrollando e integrando en el proyecto.

Desarrollo de sistemasintegrados entre sí

Los diferentes sistemas integra-dos entre sí pueden haber si-do desarrollados por distintosequipos, distintas metodolo-gías o ciclos de vida, etc.


Dentro de las estrategias incrementales existen diversas alternativas:

1)�Top�down. En esta estrategia se prueba en primer lugar el nivel superior

de la jerarquía (componente C1), y se continúa hacia abajo probando la inte-

gración con cada una de las capas. Puede suceder que los módulos o compo-

nentes inferiores (por ejemplo, C2, C3 y C4) no estén todavía preparados o

desarrollados. Para dar solución a esta problemática, se puede crear un código

"maniquí2" pequeño que simule a C2, C3 y C4 y devuelva valores esperados al

componente superior (C1). Este código simulado se llama stub.

Los stubs simulan las funciones de los módulos inferiores que el módulo

probado solicita. Un stub devuelve un valor "predefinido" al módulo

que lo llama a fin de que pueda continuar con la ejecución.

(2)En inglés, dummy.

2)�Bottom-up. Las interfaces de los componentes de los niveles más bajos son

las primeras que se prueban. En este caso puede suceder que los componentes

superiores no estén preparados o finalizados. Para suplirlo podemos crear pe-

queños códigos "maniquí" que simulen los componentes superiores y pasen

valores específicos al componente que queremos probar para ver que su fun-

cionamiento es el esperado. A este código simulado se le llama driver.

Los drivers simulan el comportamiento de los módulos superiores (to-

davía no desarrollados) que llaman al módulo probado. Un driver pasa

parámetros prefijados al módulo probado y comprueba que el resultado

recibido es el esperado.

Maniquíes

Tanto los drivers como losstubs son "maniquíes", porqueno ejecutan comportamientoreal, sino que de forma muysencilla pasan y recogen valo-res prefijados y conocidos, sintratarlos.


3)�Integración�funcional. En este caso la integración se realiza por área fun-

cional.

4)�Sandwich. Es una estrategia mixta, en la que los módulos o componentes

de alto nivel se integran de forma top-down y los componentes de bajo nivel

con bottom-up.

1.2.3. Pruebas de sistema

Las pruebas de sistema están dirigidas a probar el sistema de forma completa,

en función de los riesgos y especificaciones de los requisitos, procesos de ne-

gocio, casos de uso u otras descripciones del sistema.

Una prueba de sistema ejecuta una transacción de negocio completa, desde

el punto de vista del usuario, desde la pantalla de introducción de los datos

hasta la respuesta que da el sistema a estos datos.

Ejemplo

En nuestro sistema VCV probar cómo funciona una reserva concreta desde que se esco-gen los datos de la reserva hasta que se efectúa la compra y se imprime el billete. Inter-namente, los componentes pueden efectuar funciones en las que se llaman entre sí, oefectuar operaciones unitarias que habrán sido verificadas con pruebas de integración yunitarias, pero en la prueba de sistema solo comprobamos que la visión como un todofunciona correctamente.

En general, es en este nivel de pruebas donde se invierten más esfuerzos y se

focaliza el mayor número de tipo de pruebas (rendimiento, funcional, usabi-

lidad, seguridad, etc.).

1.2.4. Pruebas de aceptación

Una vez se han corregido todos los defectos encontrados en los niveles pre-

vios, el sistema se entrega al usuario o cliente para que realice las pruebas de

aceptación. Durante estas pruebas, el cliente tiene que validar que el desarrollo

ha cumplido lo que se requería de él y no hay riesgos en la puesta en marcha

del aplicativo.

Existen diferentes tipos de pruebas de aceptación:

1)�Pruebas�de�aceptación�de�usuario. Las realizan los usuarios y gestores del

aplicativo. Su objetivo es probar su funcionalidad.


2)�Pruebas�de�aceptación�operacional3. Estas pruebas son realizadas por el

administrador de sistemas. En estas pruebas se comprueba la facilidad de ins-

talación del aplicativo, el funcionamiento de las copias de seguridad, la recu-

peración de fallos, las tareas de mantenimiento del aplicativo y se revisan pe-

riódicamente las vulnerabilidades de seguridad.

3)�Pruebas�de�aceptación�contractual�y�de�reglamento. Se verifica el sistema

de acuerdo con los criterios que se definieron en el contrato con el proveedor, y

el cumplimiento con estándares gubernamentales, legales y de seguridad (por

ejemplo, el cumplimiento con la Ley Orgánica de Protección de Datos, LOPD).

(3)También llamadas pruebas depreparación operacional.

4)�Pruebas�alpha�y�beta. Si el sistema ha sido desarrollado como un paquete

comercial destinado a la venta, las pruebas de aceptación de usuario no son

posibles, ya que los usuarios son desconocidos. En este caso se usan dos tipos

de pruebas, ordenadas en el tiempo en dos fases:

a) En la primera fase se realizan pruebas alpha. En este tipo de pruebas se

invita a participar a usuarios potenciales y desarrolladores para que prueben el

aplicativo en la ubicación del equipo de desarrollo, y se registran los defectos

encontrados.

b) En la segunda fase se realizan pruebas beta, donde el sistema es enviado a

un conjunto de usuarios a fin de que lo instalen y lo prueben bajo condiciones

reales (datos, procesos, etc.). Los usuarios envían las incidencias detectadas y

estas son corregidas por el desarrollo. Estos usuarios no tienen ningún contac-

to con los desarrolladores.

1.3. Tipos de prueba

COTS

En inglés, el software desarro-llado como paquete comer-cial se llama commercial off theshelf (COTS).

Los tipos de prueba permiten definir de forma clara los objetivos de los dife-

rentes niveles de prueba. Dentro de un nivel podemos ejecutar diferentes ti-

pos de prueba, cada uno con un objetivo específico, como probar una función

de un componente o sistema, la estructura de un componente o sistema, una

característica de calidad no funcional (como la usabilidad o el rendimiento) o

la verificación de los cambios realizados en el software (como la confirmación

o la regresión).

1.3.1. Tipo de pruebas según características de calidad

De acuerdo con las características de calidad que se prueban, podemos dife-

renciar los siguientes tipos de prueba:

Nota

Podemos realizar pruebas derendimiento en el nivel unita-rio, el nivel de integración o elnivel de sistema, entre otros.


1)�Pruebas�funcionales. Su objetivo es validar la funcionalidad del sistema.

Se incluyen en ellas la validación de las características de calidad: idoneidad,

interoperabilidad, seguridad, precisión y cumplimiento. Acostumbran a aso-

ciarse de forma incorrecta con las técnicas de caja negra, ya que estas se pue-

den aplicar también a las pruebas no funcionales.

b)�Pruebas�no�funcionales. Su objetivo es validar los criterios de calidad no

funcionales y comprobar cómo funciona el software. Dentro de las pruebas no

funcionales se incluyen, entre otras, las pruebas de rendimiento, las pruebas de

carga, las pruebas de estrés, las pruebas de usabilidad, las pruebas de facilidad

de mantenimiento, las pruebas de fiabilidad y las pruebas de portabilidad.

Tipos de prueba no funcional Descripción

Pruebas de diseño Se comprueba el diseño de la interfaz, si sigue una guía de estilounificada, una gestión de colores correcta, etc.

Pruebas de corrección idiomática y ortográfica Se valida la ortografía de los literales mostrados, la corrección endiferentes idiomas, etc.

Pruebas de compatibilidad Se comprueba que la aplicación funciona de forma correcta en di-ferentes entornos (sistemas operativos, navegadores web, etc.).

Pruebas de rendimiento: carga, volumen, estrés y estabilidad • Pruebas de carga. Tienen como objeto validar el correcto com-portamiento de la aplicación en determinadas condiciones decarga (con diferente número de accesos simultáneos de usua-rios a la vez).

• Pruebas de volumen. El objetivo es ver cómo se comporta elsistema con grandes cantidades de datos/ficheros.

• Pruebas de estrés. El objetivo es ver el comportamiento del sis-tema en las condiciones más extremas para poder conocer sila aplicación podrá dar servicio por encima de las condicionesesperadas.

• Pruebas de resistencia o de estabilidad. Este tipo de prueba tienecomo objetivo determinar si una carga continua esperada nodegrada el sistema. En general, se utiliza para encontrar si hayalgún problema de fugas de memoria en la aplicación.

Pruebas de seguridad El objetivo de estas pruebas es la detección de vulnerabilidades deseguridad en el software.

Pruebas de usabilidad y accesibilidad4 Implican medir aspectos como el rendimiento de uso que hace elusuario (cuánto tiempo o pasos utiliza para completar sus tareasbásicas), cómo recuerda el usuario la utilización después de perío-dos de no utilización, criterios de accesibilidad, etc.

(4)La accesibilidad es la capacidad que tiene el software para ser utilizado por personascon discapacidades.

3)�Pruebas�estructurales. Las pruebas estructurales, también llamadas pruebas

de caja blanca por la técnica que se usa en ellas, se basan en analizar el código

fuente para observar cómo se comporta el sistema internamente.

Técnicas de caja negra

Las técnicas de caja negra secaracterizan por basarse enprobar el comportamiento delsistema desde un punto ex-terno, sin importar cómo es-té construido internamente elsoftware.


1.3.2. Pruebas de confirmación y regresión

Cuando se realizan cambios en un software (como resultado de una petición

de mejora o un correctivo de defectos), hay que repetir de nuevo las pruebas

para validar que los defectos se han corregido.

Las pruebas�de�confirmación se realizan para verificar que un defecto

ha sido corregido correctamente.

Es importante que las pruebas de confirmación se ejecuten en las mismas con-

diciones en las que se ejecutaron la última vez (datos de entrada, entorno, etc.).

Si las pruebas nos dan como resultado que se ha corregido el defecto, ¿pode-

mos considerar que el software es ya correcto? La respuesta es no, ya que la

experiencia demuestra que aparecen nuevos defectos o reaparecen defectos

en otras partes del sistema que aparentemente no han sido modificados en la

corrección de un defecto. La causa más común de la aparición o reaparición

de defectos es el desconocimiento del impacto que un cambio en un módu-

lo o componente tiene en el resto de componentes. A veces, la corrección es

"frágil" y resuelve un caso pequeño, pero no cubre otros casos más generales

y específicos.

Las pruebas�de�regresión tienen como objetivo ejecutar un conjunto

de pruebas predefinidas en cada cambio que se haga en el software y nos

permiten verificar que no se han introducido defectos en otras partes

del sistema como consecuencia de las correcciones.

Debido a la necesidad de repetir estas pruebas en cada cambio o versión, se

acostumbran a generar y ejecutar de forma automática mediante herramien-

tas, casi nunca de forma manual.

1.3.3. Pruebas de humo

Beneficios de las pruebasde regresión

Las pruebas de regresión nospermiten comprobar que nohemos "roto" una cosa mien-tras "arreglábamos" otra.

Una prueba de humo5 es la ejecución de un subconjunto de todos los

casos de prueba definidos, que cubren la funcionalidad principal de un

componente o sistema, para determinar que las funciones más impor-

tantes van bien, sin necesidad de realizar todas las pruebas.

Origen de la expresión "prueba de humo"

La expresión "prueba de humo" proviene de la industria electrónica. Si un ingeniero dise-ña un circuito o un sistema electrónico, lo primero que hace es enchufarlo a la corrientey encender el circuito. Si sale humo, apaga el circuito y vuelve a la mesa con el soldador.Si no sale humo, continúa realizando más pruebas para ver si funciona correctamente.

(5)En inglés, smoke test


Las pruebas de humo son un paso previo a la ejecución de pruebas que pueden

revelar fallos simples y críticos, lo que evita el esfuerzo innecesario que sería

la ejecución de todos los casos de prueba planificados.

1.3.4. Pruebas manuales y automatizadas

Las pruebas pueden ser ejecutadas de forma manual, o bien de forma automá-

tica con el apoyo de herramientas. El caso más habitual de utilización de he-

rramientas de apoyo lo encontramos en los siguientes tipos de prueba:

• Revisiones�de� la�calidad�interna�del�código. Se usan herramientas de

apoyo que analizan la estructura y complejidad del código y extraen di-

ferentes métricas (complejidad ciclomática, número de líneas duplicadas,

índice de facilidad de mantenimiento...).

• Pruebas�de�rendimiento. Permiten simular la navegación en el aplicativo

de múltiples usuarios.

1.4. Tipos de entornos de prueba

Cualquiera de los implicados en un proyecto (programadores, probadores,

usuarios, etc.) desea que su trabajo no sea interrumpido por nadie.

Ejemplo

Se ha finalizado el desarrollo de la nueva versión 2.6 del aplicativo del sistema VCV, quecorrige algunos de los defectos de la versión 2.5 que actualmente utilizan los usuarios. Sisustituimos la versión 2.5 por la versión 2.6 y hacemos las pruebas en paralelo, mientraslos usuarios acceden podemos impactar en su trabajo (por ejemplo, si hacemos pruebas derendimiento, ello les provocaría lentitud en el acceso). Incluso algunas de las funcionesprevias podrían dejar de funcionar en la nueva versión (imaginad el efecto que eso tendríaen los usuarios).

Para evitar conflictos entre los diferentes implicados con distintos objetivos,

las infraestructuras suelen estar divididas en cuatro tipos de entorno:

1)�Entorno�de�desarrollo. En este tipo de entorno se ejecutan las pruebas

unitarias.

2)�Entorno�de�pruebas. En este tipo de entorno se ejecutan las pruebas de

integración o las pruebas de sistema (podemos tener entornos específicos para

realizar unas u otras pruebas).

3)�Entorno�de�aceptación. En este tipo se ejecutan las pruebas de aceptación.

4)�Entorno�de�producción. Es un tipo de entorno en el que el aplicativo es

utilizado por los usuarios reales.

Pruebas sin herramientasde apoyo

Antiguamente, sin la existenciade herramientas de apoyo a laspruebas de rendimiento, cual-quier prueba de rendimientotenía que reunir físicamente avarios usuarios (podrían reque-rirse más de 50 usuarios, porejemplo) que tenían que regis-trar los tiempos obtenidos enun cuestionario.


De acuerdo con esta clasificación, un proyecto puede tener más de una ins-

tancia de entorno de cada tipo, tal como se ve en la tabla siguiente.

Tipo de entorno Entornos Propietario

Entorno de desarrollo • Entorno de desarrollo local (el del PC de cada desarrollador)• Entorno de desarrollo central

Proveedor de desarrollo

Entorno de pruebas • Entorno de pruebas de integración• Entorno de pruebas de sistema

Organización del cliente

Entorno de aceptación • Entorno de pruebas de aceptación/entorno de preproducción Organización del cliente

Entorno de producción • Entorno real de producción• Entorno de apoyo de producción (en caso de caída del principal)

Organización del cliente

El entorno de aceptación tiene que ser idéntico al entorno de producción con

el fin de minimizar los riesgos de fallos o defectos dependientes del entorno

(configuración de los servidores, balanceo, encaminadores y firewalls, etc.) y

reproducir una situación fiel a lo que será un uso regular del sistema (volumen

de datos de prueba iguales a los de producción...).

1.5. El proceso de pruebas. Actividades y entregables

Todo proceso de desarrollo incluye un conjunto de fases, entregables, proce-

dimientos y pasos que hay que realizar para producir un aplicativo. Dentro de

este proceso se encuentran relacionados con otros procesos, como el de prue-

bas, que se compone de las fases mostradas en la siguiente figura.

Las fases son secuenciales, pero en un proyecto concreto pueden superponerse,

realizarse en paralelo e incluso repetirse. En cada una de estas fases se generan

diferentes tipos de entregables, que estudiaremos en los siguientes subaparta-

dos.

Elementos de un entorno

Un entorno contiene elemen-tos específicos físicos y lógicos:elementos de red, servidoresweb, servidores de aplicacio-nes, servidores de base de da-tos, etc.


1.5.1. Planificación y control

El objetivo de la planificación de las pruebas es definir la misión de las pruebas

en el proyecto, analizando las necesidades del cliente y del propio proyecto,

así como sus riesgos. A ser posible, tiene que realizarse en paralelo con la pla-

nificación del proyecto.

Una planificación "ideal" de las pruebas incluye un plan exhaustivo de prue-

bas, que comprende la realización de pruebas unitarias para todos los compo-

nentes, pruebas de integración para todas las integraciones posibles y pruebas

de sistema completas. Este plan asegura una calidad máxima, pero requiere

un esfuerzo muy grande en recursos y una duración larga para su realización.

Debido a que no se puede probar todo, tenemos que definir muy claramente el

alcance de las pruebas en función de los riesgos del proyecto y las necesidades

del cliente. Los pasos que tendremos que realizar durante esta fase son:

1) Definir el alcance de las pruebas. Se identifica lo que queremos probar u

"objeto de las pruebas" y la información que usaremos para definir las pruebas

o la "base de pruebas" (documento de especificación funcional, técnico...).

2) Definir el enfoque. Se determina qué técnicas de prueba se usarán, las he-

rramientas de soporte a las pruebas y qué métricas se recogerán (cobertura de

las pruebas...).

3) Determinar los criterios para poder iniciar las pruebas (herramientas insta-

ladas, plataformas de hardware disponibles, datos de prueba preparados, etc.).

4) Determinar los criterios para finalizar las pruebas.

Ved también

En los siguientes apartados ve-remos diferentes técnicas deprueba.


El criterio de salida o finalización es un conjunto de condiciones, acor-

dadas con el cliente, para proceder de forma oficial al cierre del proceso

de pruebas y evitar que una tarea considerada completa haya obviado

algunas partes no realizadas.

Algunos criterios de finalización son:

a) Se han cumplido los objetivos definidos en cobertura de las pruebas.

b) La tasa de detección de defectos del período (semana, mes...) se encuentra

por debajo del umbral previamente definido.

c) El coste marginal para encontrar el siguiente defecto excede al de la pérdi-

da esperada por este defecto. Cuando iniciamos las pruebas es relativamente

sencillo y "barato" encontrar los primeros defectos. A medida que avanzamos

en el tiempo, el tiempo necesario para encontrar defectos es mayor. Tenemos

que evaluar si el tiempo y coste de las pruebas es superior al impacto por la

aparición de defectos en producción no detectados en las pruebas.

5) Determinar el esfuerzo, los recursos y los roles. Especificar los costes y re-

cursos necesarios para realizar las pruebas.

Boris Beizer

Boris Beizer escribió que nohay un criterio racional, únicoy válido para definir cuándotenemos que parar las prue-bas. Todo depende del pro-ducto, el entorno, la cultura yla aversión al riesgo.

Riesgos

La dirección puede forzar a en-tregar el producto (por pre-siones, fechas comprometi-das, etc.). En este caso, es im-portante que, como probado-res, sepamos transmitir a la di-rección el riesgo de puesta enmarcha.

Toda la información especificada en la planificación se recoge en el documen-

to de plan de pruebas. Sin embargo, en la mayoría de proyectos, los diferentes

niveles de prueba requieren recursos, métodos y entornos diferentes. En este

caso es mejor describir un plan separado para cada nivel y especificar un plan

maestro que establezca los puntos comunes a todos los niveles y la interrela-

ción entre los niveles.

1.5.2. Análisis y diseño

El objetivo del análisis y diseño es transformar los objetivos definidos en el

plan de pruebas en diseños concretos de prueba, con sus condiciones y casos

de prueba.

IEEE 829

El estándar IEEE 829 (estándarpara documentación de prue-bas de software) especifica losdiferentes documentos que seproducen durante el procesode pruebas.


Los pasos que se deben realizar durante esta fase son: identificar las condicio-

nes de prueba, crear los casos de prueba y diseñar los procedimientos de prue-

ba.

Identificar las condiciones de prueba

A partir de la base de pruebas habremos de determinar qué características ten-

dremos que probar mediante condiciones de prueba.

Una condición de prueba es un aspecto o atributo de un componente

o sistema que puede ser verificado por una prueba.

Como norma general, la condición de prueba estará formada por un condi-

cional más el resultado esperado.

Ejemplo

Si se escoge un asiento ya ocupado en el sistema VCV, se mostrará el mensaje "El asientoya está reservado, por favor, seleccione otro asiento".

El diseño de prueba es el documento que especifica las condiciones de

prueba de un elemento a probar, el enfoque detallado de las pruebas y

los casos de prueba asociados.

Las diferentes condiciones de prueba para un componente o grupo están re-

cogidas en el documento "Especificación de diseño de prueba". En él tiene que

aparecer toda la información relacionada con las condiciones de prueba, ade-

más de la lista de casos de prueba que se asociarán a estas condiciones.

Ved también

Los casos de prueba se creanen el siguiente paso, que ve-remos a continuación en elsubapartado "Especificar loscasos de prueba".


El número de diseños de prueba que tendremos que definir dependerá del ni-

vel de pruebas y de las características del objeto de prueba. En pruebas uni-

tarias podremos tener en general un diseño de pruebas por componente, en

pruebas de integración algunos grupos por interfaz y en pruebas de sistema y

aceptación varios grupos.

Especificar los casos de prueba

Las condiciones de prueba pueden ser incompletas o poco específicas, lo que

da un cierto margen de posibilidades a quien realiza la prueba, y se tienen que

concretar para poder ejecutar las pruebas.

Ejemplo

En el aplicativo VCV, para la condición de prueba definida en el diseño de prueba "com-probar que no se puede seleccionar un asiento ya ocupado", el caso de prueba tendrá queutilizar datos concretos (¿Qué usuario registrado tengo que probar?, ¿qué vuelo?, ¿quéasiento específico tengo que escoger?).

Para los diferentes valores de entrada (o un subconjunto de ellos, por ejemplo,

como veremos con las técnicas de diseño de pruebas) tendremos que conocer

cuáles son los resultados esperados y describirlos en la prueba.

Un caso de prueba6 es un elemento de prueba que incluye un conjun-

to de entradas de prueba y unas condiciones de ejecución (resultados

esperados, entorno...).

El caso de prueba tendrá que contener la siguiente información:

• Especificaciones�de�entrada. Se especifica cada una de las entradas que

se requieren para ejecutar el caso de prueba, definidas por valor (con um-

brales y tolerancias, caso de que sea posible) o referencias a tablas, fiche-

ros, etc.

• Especificaciones� de� salida. Salidas y comportamiento esperado (por

ejemplo, el tiempo de respuesta) requerido por los elementos de prueba.

• Necesidades�de�entorno. Programas y hardware para la configuración,

ejecución y registro de resultados.

• Dependencias�entre�casos�de�prueba. Lista de los identificadores de los

casos de prueba que tienen que ser ejecutados previamente a este caso de

prueba.

(6)En inglés, un caso de prueba sellama test case.


Ejemplo

En el aplicativo VCV, antes de ejecutar el caso de prueba para comprobar que no se puedereservar el asiento 6 del vuelo AB20043 previamente reservado, tendremos que ejecutarel caso de prueba que crea la reserva donde se escoge el asiento 6.

Para un diseño de prueba podemos tener varios casos de prueba, por ejemplo,

para probar varios escenarios en función de diferentes valores de entrada.

1.5.3. Implementación

Algunos casos de prueba tienen que ser ejecutados en conjunto en una secuen-

cia específica. Por ejemplo, un caso de prueba puede realizar la autenticación,

otro registrar una reserva de vuelo, otro consultar las reservas realizadas, otro

los puntos obtenidos de fidelización, etc. Todos ellos tienen que ser ejecutados

en el orden correcto, o no podremos evaluar lo que queremos probar.

El objetivo de la implementación es organizar de forma adecuada y ordenada

los casos de prueba definidos en el diseño en procedimientos. Estos describen

en detalle los pasos para ejecutar un conjunto de casos de prueba.

Un procedimiento de pruebas es un documento que describe los pasos

que se tendrán que ejecutar para un conjunto de casos de prueba.

¿Cuál es la mejor forma de estructurar nuestros casos de prueba para definir

nuestros procedimientos? Existen dos posibilidades:

1)�Casos�de�prueba�en�cascada. Se encadenan diferentes casos de prueba para

realizar todos los pasos. Por ejemplo, el primer caso de prueba comprueba

una característica del programa y deja el programa en un estado que permite

ejecutar el segundo caso de prueba.

Ejemplo

En el aplicativo VCV queremos comprobar el flujo siguiente:

1) Reservar vuelo.

2) Consultar vuelos reservados.

3) Cancelar reserva.

La ventaja de este estilo es que los casos de prueba son más pequeños y simples,

y pueden ser reutilizados en otros casos de prueba en cascada. Su desventaja

es que podemos llegar a tener muchos casos de uso "ficticios" y complicar su

gestión.

Autenticación

Un ejemplo típico de caso deprueba reutilizado es el de au-tenticación o login.


2)�Casos�de�prueba�independientes. Cada caso de prueba es autocontenido

y no requiere que se hayan ejecutado previamente otros casos de prueba para

poder ser ejecutado. Su ventaja es que se pueden ejecutar en cualquier orden,

pero acostumbran a ser grandes y complejos, no reutilizables, y difíciles de

diseñar y mantener.

Una vez definido el documento del procedimiento, se puede evaluar si este

se puede automatizar con una herramienta, mediante un código que se llama

guión o script.

1.5.4. Ejecución

La ejecución de las pruebas se inicia con la recepción de los elementos de prue-

ba que se tienen que probar. Para validar que estos elementos de prueba están

preparados, se solicita previamente al equipo un documento llamado informe

de�transmisión, en el que se especifican qué elementos son entregados para

las pruebas, dónde encontrarlos, qué cambios hay en los elementos (resultado

de correctivos y evolutivos) y una aprobación formal que indica que el aplica-

tivo se puede desplegar con garantías.

Ejemplo

Si durante el desarrollo del VCV tenemos que hacer un análisis del código, requeriremosque se nos indique dónde descargar el código fuente, ya sea un repositorio de códigofuente, ya un servidor FTP o incluso un CD entregado en mano.

Durante la ejecución realizaremos las siguientes actividades:

• Ejecutar los procedimientos de prueba definidos (de forma manual o au-

tomática).

• Registrar las operaciones realizadas en el documento de bitácora�de� la

prueba, indicando la persona que ha realizado las pruebas, la hora de ini-

cio y finalización de las mismas y los diferentes acontecimientos, situacio-

nes o problemas que hayamos encontrado durante su ejecución.

Ejemplo

He tenido que repetir la prueba a las 13:30 porque el servidor se ha caído de repente.

• Comparar los resultados obtenidos en la ejecución con los resultados es-

perados. Si no son coincidentes, registrarlo como una incidencia en el sis-

tema de gestión de incidencias o defectos.

Ved también

Dentro del subapartado 6.3.1de este módulo veremos cómose puede llegar a automatizaruna prueba.


1.5.5. Evaluación del criterio de salida e informe de resumen

Al final de la ejecución de cada uno de los niveles de prueba tendremos que

evaluar si se ha alcanzado el criterio de finalización definido en la planifica-

ción, realizando las siguientes tareas:

• Medir el progreso de finalización de las pruebas, de acuerdo con los cri-

terios de finalización definidos en la planificación, y compararlo con la

información registrada en la bitácora y los defectos encontrados.

• Evaluar si el criterio de finalización se tiene que cambiar o se necesita rea-

lizar más pruebas.

• Si se validan los criterios de finalización, generar un informe de resumen

de las pruebas para el cliente en el que se resuma cómo han ido las prue-

bas, el número de fallos encontrados y el de pendientes de corregir, y la

valoración global de la calidad del software del sistema o aplicación.

1.5.6. Cierre

En el cierre consolidamos la experiencia obtenida en la realización de las prue-

bas (errores de estimación, causas más comunes de los errores en el equipo

de pruebas, procedimientos que se pueden reutilizar, etc.) y se introducen en

el sistema de gestión de la configuración todos los elementos usados en las

pruebas (documentos, scripts, datos, configuración de entornos, etc.).

1.6. Técnicas de diseño de prueba dinámicas

Es imposible probar todos los casos posibles de un software. Si tenemos en

cuenta los diferentes flujos posibles de navegación o las combinaciones de da-

tos de entrada y de salida, el número de casos de prueba resultantes podría

llegar a ser muy grande. Por lo tanto, se tiene que establecer alguna estrategia

que nos permita simplificar el problema y afrontarlo de forma viable (en pre-

supuesto y tiempo) mediante la selección y el uso de técnicas de prueba.

Una técnica de diseño de prueba permite simplificar una prueba, alcan-

zando una cobertura adecuada sin tener que ejecutar todas las casuísti-

cas posibles.


Las técnicas de prueba pueden clasificarse en estáticas y dinámicas. Las prime-

ras se pueden aplicar a elementos no ejecutables (código fuente, documentos

funcionales, documentos técnicos, manuales de usuario, etc.) mientras que las

técnicas dinámicas se usan para probar software en ejecución.

Usos de las pruebas estáticas y dinámicas

De acuerdo con la diferenciación entre defecto y fallo, podemos establecer que las prue-bas estáticas permiten encontrar defectos (se identifica qué se tiene que corregir) mien-tras que las pruebas dinámicas, o simplemente pruebas, permiten identificar fallos (pos-teriormente se tendrá que encontrar con la depuración el defecto que los produce).

Técnicas estáticas Técnicas dinámicas

El software no se ejecuta. Se ejecuta el software.

Se comprueba que el código cumple buenasprácticas, su complejidad, etc. (con el apoyo,en general, de una herramienta).Se comprueban de forma manual los docu-mentos.

Se examina la respuesta física del sistema en laintroducción de parámetros de entrada.

Se buscan defectos. Se buscan fallos.

Pertenecen a las actividades de verificación. Pertenecen a las actividades de validación.

Ejemplos: Revisiones manuales y análisis estáti-co de la calidad del código.

Ejemplos: Pruebas unitarias, pruebas de in-tegración, pruebas de sistema y pruebas deaceptación.


Las técnicas dinámicas se dividen en:

1)�Basadas�en�la�especificación. Las pruebas se concentran en lo que hace el

software, más que en cómo lo hace.

Técnicas de caja negra

Las pruebas basadas en la especificación se llaman también técnicas de caja negra, porquese considera el software como una caja negra con entradas y salidas, pero sin que hayaningún interés en saber cómo está estructurado el componente internamente ("dentrode la caja").

2)�Basadas�en�la�estructura. Se llaman también técnicas de caja blanca porque

los casos de prueba son definidos de acuerdo con el conocimiento que se tiene

de la estructura interna del código y de cómo está implementado.

3)�Basadas�en�la�experiencia. Se basan en aprovechar la experiencia y habi-

lidades de los diferentes implicados en el proyecto para definir los casos de

prueba y sus condiciones.

4)�Basadas�en�defectos. Estas técnicas están dirigidas a diseñar los casos de

prueba para encontrar una o más categorías específicas de defectos.

5)�Análisis�dinámico. El objetivo es analizar la aplicación mientras se está

ejecutando (evaluando el comportamiento de la red, la memoria del sistema,

etc.).

Todas las técnicas son complementarias, pudiendo aplicar varias técnicas a

una misma prueba.

1.6.1. Técnicas dinámicas basadas en la especificación

Las técnicas de caja negra o basadas en la especificación se utilizan para

diseñar los casos de prueba en función de la especificación o descripción

del producto, sin importar cómo esté construido por dentro.

Existen diferentes técnicas dinámicas basadas en la especificación, entre las

que podemos destacar las clases de equivalencia, el análisis de valores frontera,

las tablas de decisión, las pruebas basadas en estados y las basadas en casos

de uso.

Clases de equivalencia

La técnica de clases de equivalencia permite reducir el número total de

casos de prueba dividiendo el conjunto de valores en un número finito

de subconjuntos, llamados clases de equivalencia.

Ved también

En este subapartado analizare-mos las técnicas dinámicas; lastécnicas estáticas las revisare-mos en detalle en el apartado2 de este módulo.


Se considera que el software se comportará de la misma manera para todos los

miembros de una clase: si probamos un miembro de una clase y la prueba va

bien, se considera que ha ido bien para todos los miembros de la clase, y si el

resultado ha sido malo para uno de ellos, lo será también para los demás.

Habitualmente, la técnica de clases de equivalencia se aplica a intervalos nu-

méricos ([1 a 5]...), conjuntos de posibilidades ([masculino, femenino]; [clase

turista, clase business]) y valores booleanos (falso/cierto).

Cuando realizamos la división de los valores en clases de equivalencia, tene-

mos que considerar tanto las clases válidas (contienen valores que el produc-

to acepta) como las inválidas (contienen valores que el producto rechaza o

para los que no hay un comportamiento definido en el programa). Además,

un miembro o valor no puede encontrarse nunca en dos o más clases de equi-

valencia.

¿Cómo identificamos las clases de equivalencia? Aunque dependerá de cada

caso, podemos tener en cuenta que:

• Si la condición de entrada especifica un rango de valores, obtendremos

una clase de equivalencia válida y dos clases inválidas.

Ejemplo

Si la reserva de vuelos del sistema VCV solo acepta introducir el valor 1 a 50 adultos enla reserva, obtendremos una clase de equivalencia válida que incluye el intervalo [1-50]y 2 clases inválidas (valores menores de 1 y superiores a 50).

• Si la condición de entrada especifica un conjunto de lista de valores, en-

tonces tendremos una clase de equivalencia para cada valor.

Ejemplo

En el VCV se pueden escoger dos valores para la categoría del viajero: turista o business.Cada uno de ellos es una clase de equivalencia.

Nota

La técnica de clases de equiva-lencia es la más utilizada habi-tualmente.


• Si la condición de entrada incluye una validación tendremos una clase de

equivalencia para representar los valores válidos y otra para representar

los valores inválidos.

Ejemplo

En el VCV se incluye la fecha de ida del vuelo en una reserva. Tendremos una clase pararepresentar fechas válidas y otra para representar fechas inválidas (cadenas...).

• Si la condición de entrada es un valor booleano, tendremos dos clases de

equivalencia, una para el valor cierto y una para el valor falso.

Ejemplo

En el VCV se incluye un campo que permite indicar si somos o no flexibles en las fechas.En el caso de que digamos que no, el sistema propondrá también los vuelos que salganun día antes o después de la fecha escogida. En este caso tendremos dos clases, una parael valor cierto y una para el valor falso (no soy flexible en las fechas).

• En cualquier otro caso, la partición en clases dependerá de los valores y el

funcionamiento que se espera del programa.

Ejemplo

En el sistema VCV, para el cálculo de puntos de fidelización tenemos las siguientes clasesválidas: 1, {2 a 9}, {10 a 24}, {25 a 50}.

Una vez realizada la división en clases, podemos hacer diferentes pruebas en

las que cada una seleccione un valor representativo de cada clase de equiva-

lencia. Podremos medir la cobertura de las pruebas efectuadas de acuerdo con

el porcentaje de clases de equivalencia que se han probado.

Análisis de valores frontera

La técnica de análisis de valores frontera es un refinamiento de la técnica

de clases de equivalencia, orientada a probar los valores frontera, que

son los que se encuentran en la frontera de una clase de equivalencia.

Defectos y valoresfrontera

Tenemos que prestar especialatención a los valores frontera,ya que los defectos suelen en-contrarse en estos valores.


Ejemplo

Supongamos que en el ejemplo de clases de equivalencia, en el cálculo de fidelizacióndel VCV se dan las siguientes condiciones:

1) El valor escogido en las pruebas para la clase de equivalencia {10 a 24} ha sido el valor14.

2) El programador ha cometido un error7 y ha hecho el siguiente código:

if (NumAdultos>1 && NumAdultos<10) puntos=2; if (NumAdultos>10 && NumAdultos <25) puntos = 5;

Cuando lo correcto hubiera sido que la segunda sentencia fuera:

if(NumAdultos>=10 && NumAdultos<25) puntos = 5;

3) Se realizan las pruebas y se verifica que todo va bien.

4) Posteriormente, una reserva con valor 10 provoca un error que hace abortar el pro-grama.

Si nos fijamos bien, el valor escogido no nos permitió detectar el defecto.

La técnica de valores frontera se basa en seleccionar en las pruebas los valores

que limitan al inicio de la clase y a su final. Eso implica que probaremos dos

valores por cada frontera (entre clase y clase).

Ejemplo

En el caso anterior descrito del VCV, los valores frontera de cada una de las clases deequivalencia serían los representados a continuación:

Inválida Válida Válida Válida Válida Inválida

0 1 2 9 10 24 25 50 51

Nuestras pruebas tendrían que verificar el comportamiento del software con cada unode estos valores.

Hasta aquí puede parecer que todo es correcto, pero existe una ampliación de

este modelo que tiene en cuenta tres valores por cada frontera.

(7)Aunque pueda parecer extraño,es bastante habitual que los pro-gramadores cometan estos tiposde errores.

Ejemplo

Supongamos que probamos los números 10 y 24 para comprobar que se nos dan 5 puntos,pero que para el número 10 el resultado es 5 puntos y para el 24 obtenemos otro valor.¿Cómo podemos determinar cuál es el comportamiento de los valores 11 a 23? La técnicade 3 valores incluirá los 2 valores frontera y el valor siguiente al límite inferior y el valoranterior al límite superior, es decir, 11 y 23.

Inválida Válida Válida Válida Válida Inválida

-1 0 1 2 3 8 9 10 11 23 24 25 26 49 50 51 52

No todas las clases de equivalencia tienen valores frontera. Solo podemos tener

valores frontera en clases de equivalencia cuyos miembros estén ordenados (se

puede determinar cuándo un miembro es mayor o menor que otro).

Reflexión

Si bien nuestro ejemplo es sim-ple y las clases contienen unrango pequeño de valores,pensad qué ganancia obten-dríamos si el número de valo-res en cada clase fuera muchomayor (comprobar cantidadesbancarias...).


Tablas de decisión

Si el sistema realiza acciones diferentes dependiendo de las combinaciones de

los valores de entrada, no podemos aplicar las técnicas de clases de equivalen-

cia y análisis de valores frontera. Las tablas de decisión y las pruebas basadas en

estados están orientadas a probar las reglas establecidas en la lógica de negocio.

Una tabla de decisión (o tabla de "causa-efecto") es una tabla que repre-

senta las acciones del sistema (salidas) basadas en las diferentes combi-

naciones de las condiciones de entrada.

Pruebas basadas en estados

La técnica de pruebas basadas en estados es adecuada cuando queremos probar

alguna parte del sistema en la que el resultado obtenido es diferente para la

misma entrada según el estado en que se encuentre el sistema. Se basa en la

utilización de diagramas de estados.

Pruebas basadas en casos de uso

Si durante el diseño del aplicativo se han definido casos de uso, los podemos

utilizar para realizar pruebas basadas en ellos. Ejecutaremos un caso de prueba

para el escenario principal y un caso de prueba para cada extensión que se

haya especificado.

Podemos combinar las técnicas de clases de equivalencia y análisis de valores

frontera para determinar qué valores se tienen que utilizar en las pruebas ba-

sadas en casos de uso. Se puede iniciar, por ejemplo, una ejecución con valo-

res miembro de cada clase de equivalencia válida para los escenarios normales

o habituales, después el escenario normal con valores frontera inválidos, y fi-

nalmente las extensiones más críticas para el sistema.

1.6.2. Técnicas dinámicas basadas en la estructura

Las técnicas dinámicas de caja blanca, o basadas en la estructura, tienen

como objetivo cubrir con las pruebas los caminos internos que realiza

el software.

Si bien son pruebas que se pueden aplicar en todos los niveles (unitarias, inte-

gración, sistema), habitualmente las realizan los desarrolladores en las pruebas

unitarias.

Caso de uso

Un caso de uso muestra cómointeractúa nuestro aplicativocon unos o más actores. Inclu-ye las diferentes acciones querealiza en respuesta a aconteci-mientos de los actores.


En las técnicas de caja blanca diferenciamos en un programa dos elementos,

las sentencias (declaraciones, asignaciones, cálculos...) y las decisiones o con-

dicionales (if, while...).

Podemos realizar dos tipos de pruebas de caja blanca teniendo en cuenta la

anterior diferenciación:

1)�Basadas�en�sentencias. Se prueba una secuencia específica de sentencias

del programa con el objetivo de obtener una cobertura determinada, según el

porcentaje de sentencias totales que son ejecutadas por la prueba.

Ejemplo

Supongamos el pseudocódigo del sistema VCV representado a continuación.

Leer paráms. NumAdultos, import,núm.Tarjeta;

if (NumAdultos>10) { descuento=importe*(1-10%);}

if (comprobarTarjetaValida()) { cerrarReserva();} else { cancelReserva();}

Este puede ser representado por el grafo de la figura siguiente, donde se muestran en cajaslas sentencias y con rombos las condiciones. Si queremos probar todas las sentencias nosharían falta únicamente dos pruebas para pasar por todas ellas (se representa cuál seríasu flujo con las líneas discontinuas).


2)�Pruebas�basadas�en�decisiones. En este caso, la cobertura se mide por el

número de pruebas que se han definido para evaluar todas las decisiones. En

la mayoría de los casos, una decisión tendrá dos salidas, falsa o cierta, pero

una decisión puede tener más salidas, como, por ejemplo, en un switch-case.

Ejemplo

En el caso anterior del VCV si queremos pasar por todas las condiciones tendremos quehacer cuatro pruebas diferentes.

Una cobertura del 100% de decisiones garantiza siempre un 100% de cobertura

de sentencias. Es decir, si los casos de prueba definidos pasan por todas las

condiciones, ciertamente pasan por todas las sentencias.

1.6.3. Técnicas dinámicas basadas en la experiencia

Hasta ahora hemos analizado diferentes técnicas sistemáticas para encontrar

defectos, pero existen algunos defectos que no se pueden encontrar con estas

técnicas. Existen diferentes tipos de técnicas basadas en la experiencia, entre

las que podemos encontrar las técnicas de adivinación, las listas de compro-

bación y las pruebas exploratorias.

En la técnica de adivinación de errores, el probador utiliza su experien-

cia para anticipar o prever cuáles son los errores que cometerá el pro-

gramador y diseña las pruebas para exponerlos.


En las listas de comprobación se establece un conjunto predefinido de posi-

bles fallos que sabemos que suelen "escapar" a las pruebas sistemáticas. Estas

listas se obtienen y definen basándose en la experiencia recogida en proyectos

previos.

Las pruebas exploratorias son una técnica en la que un probador con

experiencia y habilidades controla y actualiza activamente el diseño de

las pruebas a medida que las ejecuta, y utiliza la información obtenida

para diseñar nuevas y mejores pruebas.

Uno de los tipos más conocidos de pruebas exploratorias es el de las pruebas

basadas�en�sesiones, útiles en proyectos con restricciones de tiempo y conti-

nuos cambios en los requisitos. Se basan en definir intervalos o sesiones de

prueba sin interrupciones de 45 a 120 minutos, en las que se realizan las si-

guientes actividades:

Cem Kaner

Cem Kaner fue el primero queintrodujo el concepto de prue-bas exploratorias.

1) Definir el objetivo de las pruebas en un documento en formato carta deno-

minado "carta de sesión8".

Ejemplo

Encontrar defectos en la realización del pago de la reserva del sistema VCV y encontrardefectos de usabilidad en el navegador Firefox 2.0.

2) Ejecutar las pruebas. A medida que se ejecutan las pruebas, analizar sus re-

sultados y pensar qué variaciones se podrían realizar en las pruebas. Se regis-

tran los defectos encontrados en la carta de pruebas.

3) Aislar y documentar los defectos. Una vez se hayan hecho una o dos cartas

de prueba, se recogen los defectos encontrados y se intenta saber cómo repe-

tirlos de forma determinista. Se anota en la carta cómo reproducirlos.

4) En el último paso se evalúan los resultados obtenidos en la sesión y se pla-

nifica la siguiente sesión.

Esta técnica tiene un gran carácter de adaptación, que permite realimentar las

pruebas en función de los resultados obtenidos.

1.6.4. Técnicas dinámicas basadas en defectos

Las técnicas basadas en defectos tienen en cuenta diferentes tipologías

de defectos, bien para detectarlos, bien para introducirlos y comprobar

que las pruebas son capaces de detectarlos.

(8)En inglés, session charter.


Las técnicas basadas en defectos se pueden clasificar en:

1)�Basadas�en�taxonomías. Las pruebas son definidas para buscar una o más

categorías o taxonomías de defectos con lo que ya se sabe de dichas categorías

(qué errores se cometen, en qué áreas se encuentran habitualmente, etc.).

2)�Inyección�de�fallos. Es una técnica en la que se introducen de forma deli-

berada defectos en el código, bien de forma manual, bien con el soporte de

herramientas, para evaluar la eficiencia de las pruebas.

3)�Análisis�dinámico. Se basa en evaluar el comportamiento de un sistema

o componente durante su ejecución con el soporte de herramientas de ins-

trumentación sobre diferentes componentes del sistema (servidores, bases de

datos, red, aplicativo, etc.) para obtener en tiempo real información del fun-

cionamiento de cada uno de ellos. Nos permite encontrar defectos habituales,

como:

a)�Fugas�de�memoria�y�otros�elementos. Identificar donde se localizan las

fugas de memoria con la representación de los objetos creados y no destruidos

en el tiempo. Las herramientas son también capaces de detectar en qué puntos

no se liberan correctamente los recursos abiertos por ficheros, conexiones a

base de datos, sockets, etc.

Síntomas de una fuga de memoria

Una fuga de memoria tiene lugar cuando un software reserva un espacio de memoriapero después no es liberado por un error de programación. El síntoma de este error esel empeoramiento del tiempo de respuesta de las peticiones de los usuarios hasta que seproduce el fallo total del sistema.

b)�Análisis�del�rendimiento. Muchas aplicaciones se construyen sin tener en

cuenta los requisitos de rendimiento y carga. Las herramientas nos permiten

medir el rendimiento del aplicativo en función de diferentes escenarios de

carga e identificar "cuellos de botella".

Cuellos de botella

Los cuellos de botella son lospuntos en los que el softwarefunciona de forma ineficiente.


2. Técnicas de detección de defectos. Las revisiones y elanálisis estático

Las técnicas de detección de defectos incluyen las técnicas relacionadas con

lo que llamamos pruebas estáticas, en las que encontramos las revisiones y el

análisis estático.

2.1. Revisiones

El objetivo de las revisiones es encontrar defectos examinando entrega-

bles no ejecutables.

Tanto si consideramos las revisiones como actividades del aseguramiento de

la calidad como si son parte de las pruebas, las revisiones se diferencian de las

pruebas "clásicas" en que se realizan durante todo el ciclo de vida de desarrollo

y su objeto de estudio es cualquier tipo de entregable no ejecutable: requisitos y

especificaciones, documentos de diseño (funcional, técnico...), código fuente,

documentos de prueba, manuales de usuario, etc.

2.1.1. Tipos de revisiones. Roles y responsabilidades

Defectos de losdocumentos de prueba

Los documentos de pruebatambién pueden tener defec-tos (condiciones de pruebaambiguas, informes de resulta-dos incompletos, etc.).

Ved también

Recordad que habéis estudia-do las pruebas "clásicas" en elapartado 1 de este módulo.

Las revisiones pueden ser tanto informales como formales. Las revisiones in-

formales no tienen reglas definidas, ni roles, ni responsabilidades.

En una revisión formal, por el contrario, existen roles y responsabilidades bien

definidos:

• Líder�o�moderador. Es la persona responsable de la revisión. En coopera-

ción con el autor establece el tipo de revisión y la composición del equi-

po de revisión. Revisa la planificación, prepara las listas de comprobación,

distribuye los documentos a revisar antes de las reuniones y gestiona la

reunión de revisión.

• Autor. Es la persona que ha escrito el documento a revisar.

• Revisores. Son las personas que revisan los documentos.

• Secretario�o�escribano. Registra y documenta los problemas, defectos y

recomendaciones.

Ejemplos de revisionesinformales

Las revisiones informales pue-den ser tan simples como unaconversación en un café entredos colegas que revisan un do-cumento o un correo en el quese solicita revisar el contenidode un entregable.


Según el tipo de revisión, algunos de los roles pueden ser ejecutados por la

misma persona, y un solo documento puede ser objeto de más de una revisión.

Por ejemplo, antes de realizar una revisión técnica formal de un documento se puedehaber realizado una revisión informal del mismo.

Podemos diferenciar varios tipos de revisiones formales:

1)�Tutorial9. El autor del documento a revisar guía a los participantes a través

del documento a fin de que lo entiendan. Este tipo de revisión es especialmen-

te útil para documentos de alto nivel, como especificaciones de requisitos o

documentos de arquitectura, cuando los revisores no tienen conocimientos

de los documentos de desarrollo. El autor hace toda la preparación, y los par-

ticipantes (escogidos de diferentes ámbitos y departamentos) no tienen que

realizar un estudio previo detallado de los documentos.

(9)En inglés, walkthrough.

2)�Revisión�técnica. Su objetivo es la revisión del contenido técnico de un

documento por parte de expertos (arquitectos, diseñadores, usuarios clave...).

A veces se llaman "revisión de igual a igual10".

3)�Inspección. En este caso, el documento a revisar es preparado y evaluado

antes de la reunión por todos los revisores, que comparan el documento con

otros documentos referenciados y usan listas de comprobación. A diferencia

de los anteriores tipos de revisiones, hay un moderador que no es el autor, y

se realiza un seguimiento posterior de las anotaciones y cambios en el docu-

mento.

(10)En inglés, peer review.

4)�Revisión�de�gestión. Su objetivo es monitorizar el progreso y los riesgos

de un proyecto, sistema, actividad o proceso y tomar decisiones de mejora o

actuación. Los gestores que están implicados en el elemento a revisar son a

menudo quienes realizan estas revisiones, pero en algunos casos se contratan

consultores externos para hacer evaluaciones de procesos. El resultado de la

revisión de gestión es el establecimiento de acciones y recomendaciones.

5)�Auditoría. Se evalúa el cumplimiento de estándares, guías, especificaciones

y procedimientos en función de unos criterios objetivos (estándares, guías,

etc.). Como resultado de la evaluación se concluye si hay cumplimiento total

o no cumplimiento. Siempre se realiza por una parte independiente.

2.1.2. El proceso de revisión

Si bien un proceso de revisión informal no tiene un ciclo establecido, en un

proceso de revisión formal encontramos las siguientes fases:

Ejemplo de revisión degestión

Un ejemplo de revisión de ges-tión es el modelo SCAMPI paraCMMI que vimos en el módulo"Calidad del software: gestiónde la calidad y métricas".


1)�Planificación. El moderador realiza una comprobación preliminar del do-

cumento a revisar. Si el documento tiene demasiados errores obvios no tendrá

sentido que se haga ninguna revisión. Si el documento es correcto, el mode-

rador y el autor definen qué parte del documento se tendrá que revisar y esta-

blecen la composición del equipo de revisores.

2)�Reunión�de�lanzamiento. Durante la reunión, a la que asisten todos los

roles de participación, se establecen los objetivos de la revisión, el tiempo dis-

ponible y los criterios de finalización y se distribuye el documento.

3)�Preparación. Los participantes trabajan individualmente en la revisión del

documento e identifican defectos y preguntas o comentarios. Para la revisión

usan procedimientos, documentos relacionados y listas de comprobación.

4)�Reunión�de�revisión. La reunión se distribuye en tres fases:

a)�Fase�de�bitácora. Cada revisor comenta los diferentes defectos que ha de-

tectado durante la preparación. Estos son registrados por el secretario y se es-

tablece cuáles se tienen que discutir en la fase siguiente de la reunión. Durante

esta fase no se permite ninguna discusión o argumentación de los defectos.

b)�Fase�de�discusión. En esta fase se discute sobre los defectos anotados desde

un punto de vista positivo.

c)�Fase�de�decisión. Al final de la reunión se revisan los criterios de finalización

y se determina si se procederá a la realización de un nuevo ciclo de revisión,

una vez corregidos los defectos detectados.

5)�Corrección. En función de los defectos detectados, el autor mejora el do-

cumento. Para poder hacer el seguimiento de las correcciones tiene que indi-

car qué puntos del documento ha modificado. Se puede, por ejemplo, activar

la opción de revisión "Seguimiento de cambios" en la herramienta ofimática

usada.

6)�Seguimiento. El moderador es el responsable de validar que se han corre-

gido los defectos y se han realizado las mejoras sugeridas, bien de forma indi-

vidual, bien recogiendo la validación de los diferentes revisores.

7)�Cierre. En esta fase final el moderador recoge y analiza toda la información

que permite mejorar el proceso de revisión y establecer medidas de prevención

de los defectos detectados.


2.1.3. Listas de comprobación

Las listas de comprobación son herramientas de soporte muy prácticas

para las revisiones. Establecen un guión o lista de los elementos que tie-

nen que ser revisados o ser comprobados. Estas listas de comprobación

se construyen basándose en la experiencia y estándares.

Una lista de comprobación incluye habitualmente, para cada criterio o regla

a comprobar, dos columnas de valoración, una para indicar si se cumple (Sí,

No, No aplicable) y otra para describir la causa de la valoración. Para mejorar

su lectura, los criterios se suelen clasificar en grupos.

Criterio ¿Se cumple? Comentarios

Sí/No/No aplicable

2.2. Análisis estático

Ejemplo

Los probadores del softwareVCV utilizan una lista de com-probación para revisar la con-sistencia de las páginas webcreadas.

El análisis estático es una técnica para evaluar código y modelos (en

UML, por ejemplo) realizada con el apoyo de herramientas.

Podemos detectar, por ejemplo, si se referencia una variable que no tiene va-

lor definido, qué variables no se utilizan nunca, si existe código muerto que

nunca se ejecutará, el incumplimiento de estándares de programación, vulne-

rabilidades de seguridad, etc.

Existen tres técnicas principales de análisis estático: el análisis de la estructura

del código, la comprobación del cumplimiento de estándares de programación

y el cálculo de métricas.

2.2.1. Análisis de la estructura del código

Con la estructura del código podemos analizar su flujo de control y su flujo

de datos.

Ejemplo de análisisestático

Un compilador puede conside-rarse como un nivel básico deanálisis estático, ya que verifi-ca el código para comprobar sisu construcción es válida en ellenguaje de programación.

Con el flujo de control se evalúa la secuencia en la que las instrucciones serán

ejecutadas (bucles, condiciones, etc.) para poder detectar, entre otros, código

muerto y funciones que nunca son llamadas.

Código muerto

El código muerto es una re-gión del código que no seráejecutada nunca porque no seestablece ningún condicionan-te para llegar a ella (una condi-ción siempre falsa, una salidade la función previa, etc.).


El flujo de datos permite analizar cómo un elemento de datos –una variable– es

accedido y modificado en el código. Podemos detectar el uso de una variable

sin definir (sin valor), variables que nunca son usadas o variables que se usan

después de haber sido destruidas.

2.2.2. Cumplimiento de estándares de programación

Mediante una herramienta de análisis estático de código se puede verificar el

seguimiento de cualquiera de las convenciones definidas en un estándar de

codificación o programación.

Por ejemplo, se puede comprobar, entre otros:

• Seguimiento de convenciones de nombres de las clases, métodos, paráme-

tros.

• Seguimiento de buenas prácticas de programación: uso de cadenas, litera-

les, concatenación, seguridad, inicialización de variables fuera de los bu-

cles, etc.

• Seguimiento de formato: número de líneas por método, por clase, inden-

taciones, etc.

2.2.3. Cálculo de métricas de código

Ved también

En el apartado 4 de este mó-dulo podéis encontrar la defi-nición de estándar de progra-mación y cuáles son sus bene-ficios.

Cuando se realiza el análisis estático del código se extrae información de su

estructura interna, como, por ejemplo:

• Líneas de código

• Complejidad ciclomática

• Índice de mantenibilidad

• Fan-in y fan-out

• Número de descendientes

Las diferentes medidas obtenidas tienen que ser evaluadas y comparadas con

el tiempo para comprobar si se están realizando mejoras en el código o estamos

empeorando su calidad.

Nota

Podemos recoger todas lasmétricas de producto que ana-lizamos en el módulo "Calidaddel software: gestión de la cali-dad y métricas".


3. Técnicas de localización y corrección de defectos

3.1. La depuración

El proceso de depuración11 consiste en buscar, analizar y eliminar las

causas de un fallo.

Una vez se ha encontrado un fallo –bien por parte de un usuario, bien en

las pruebas–, algún programador tiene que realizar la localización o diagnosis

del defecto y corregirlo. Este proceso, llamado depuración, se divide en cuatro

fases:

1)�Reproducción�del�fallo. Se busca cómo reproducir el fallo varias veces, de

forma determinista.

2)�Diagnóstico. Se construyen y prueban diferentes hipótesis, hasta tener la

confianza y seguridad de que se ha identificado el defecto.

3)�Corrección. Se diseña e implementa la solución que corrige el problema,

evitando impactar sobre otras partes del aplicativo y manteniendo el nivel

adecuado de su calidad.

4)�Reflexión. Se evalúa por qué ha tenido lugar el fallo y si hay otras áreas en

el aplicativo en las que se puedan encontrar defectos similares. Se registra y

comunica toda la información para prevenir la aparición de defectos similares

en el proyecto y otros proyectos de la organización.

3.1.1. Reproducción del fallo

El primer paso que un programador tiene que realizar para reproducir un fallo

es analizar su informe de incidencia.

Falta de información del fallo

Algunos usuarios y probadores poco experimentados no informan de las condiciones enque se ha reproducido el fallo (versión del aplicativo, sistema operativo, navegador, etc.).Eso hace que sea habitual encontrar incidencias cerradas por programadores con motivode resolución "No se puede reproducir", sin ni siquiera haber intentado reproducirlas.

Es importante que se conozcan las condiciones en que se ha reproducido el

fallo (preguntando al usuario o al probador, si es necesario) y que el programa-

dor configure un entorno similar al entorno en que se ha reproducido el fallo:

(11)En inglés, debugging.

Herramientas dedepuración

No debemos confundir el pro-ceso con las herramientas desoporte al desarrollo, como ladepuración. Las herramientasde depuración ofrecen utili-dades para poder analizar entiempo de ejecución y en elcódigo cuál es el estado de susvariables, o ver qué camino es-tá siguiendo el software.

Tiempo de depuración

La reproducción del fallo y eldiagnóstico pueden represen-tar hasta un 95% del tiempototal de la depuración.


1)�Versión�del�software. La versión del software o aplicativo que se encuentra

desplegada en producción puede no coincidir con la que tiene el desarrollador.

En este punto juega un papel importante la gestión de la configuración, ya

que el desarrollador tendrá que bajarse el código fuente de la versión corres-

pondiente, compilarla y ejecutarla.

2)�Entorno. Es probable que el programador no pueda reproducir un fallo en

su entorno local de desarrollo si no ejecuta el aplicativo en las mismas condi-

ciones que el entorno servidor de producción (sistema operativo, red, capaci-

dades de almacenamiento, servidor...) y el entorno del usuario (navegador, sis-

tema operativo, software de soporte, etc.). Si bien existen determinadas condi-

ciones que pueden ser ejecutadas de forma independiente por cada fallo, otros

no se pueden ejecutar de forma independiente fácilmente. Con la virtualiza-

ción podemos llegar a resolver esta problemática.

Ejemplo de uso de la virtualización

Se puede probar fácilmente si el fallo se reproduce en Google Chrome 5.0 y no en InternetExplorer 4.0, porque no existen incompatibilidades entre los dos si están instalados enla misma máquina que hace las pruebas. En cambio, no se puede reproducir en unamáquina un fallo en dos sistemas operativos diferentes (Ubuntu y Windows, o WindowsVista i Windows 7, por ejemplo), salvo que se recurra al uso de la virtualización.

Sin embargo, habrá condiciones que solo podrán ser reproducidas en entornos

reales, debido a las necesidades de capacidad del procesador, la configuración

de la red y otros elementos de los que no se puede disponer fácilmente por

su coste.

Virtualización

La virtualización es un meca-nismo bastante utilizado parapoder disponer de diferentesconfiguraciones en un mismoentorno que pueden ser ejecu-tadas de forma independiente.

3)�Datos. Los datos de entrada que han provocado el fallo son relevantes para

reproducirlo. Si en el registro de incidencia no se aporta información sobre los

datos utilizados se tendrá que inferir o registrar de forma previa, por ejemplo,

con rastros o bitácoras de la ejecución del software. Caso de que se tenga que

inferir, se puede seguir, por ejemplo, la técnica de análisis de valores frontera

o la técnica de cobertura de ramas. Caso de que el fallo se dé bajo condiciones

de alta concurrencia de usuarios, tendremos que recurrir a la realización de

pruebas de rendimiento y simular una carga de usuarios que permita reprodu-

cir el fallo.

3.1.2. Diagnóstico

Durante el diagnóstico tenemos que experimentar las posibles causas del de-

fecto:

Ved también

Analizaremos la bitácora o log-ging en el subapartado 3.2 deeste módulo.


• Examinando el estado interno del software con una instrumentación di-

recta o ejecutando una herramienta de depuración.

• Modificando algún aspecto del software que permita identificar si se com-

porta de forma diferente (cambiando datos, cambiando a otro entorno,

etc.).

Ejemplo

Supongamos que tenemos un problema en la función de búsqueda de los vuelos del sis-tema VCV que provoca una pérdida de memoria. Sabemos que el defecto se encuentra enun método concreto, pero no sabemos dónde dentro de las 50 líneas del método. Pode-mos introducir en el código un "chivato" en la mitad del método y escribir por pantallacuál es la memoria disponible para comprobar si hemos perdido memoria. Si el resulta-do es que sí, podemos inferir que la pérdida se encuentra en la primera mitad. Despuéspodremos meter el "chivato" en la mitad de la primera mitad, y así sucesivamente hastalocalizar la línea concreta donde se encuentra el defecto.

• Modificando la lógica del código fuente del programa para ver el efecto

del cambio.

Instrumentación

La instrumentación es la in-troducción de código que noafecta al comportamiento delprograma. El método más co-mún es el uso de rastros o log-ging. Ver este método un pocomás adelante en el subaparta-do 3.2 de este módulo.

• Comparando el estado actual con estados previos en los que no se repro-

ducía el fallo. Si, por ejemplo, se sabe a ciencia cierta que un fallo ya fue

corregido en una versión anterior, podemos usar el histórico que mantie-

ne el sistema de control de versiones de código para analizar qué líneas de

código fuente se han añadido, eliminado o cambiado, y averiguar si estos

cambios son los que han provocado el fallo.

En general, los desarrolladores introducen diferentes cambios a la vez para in-

tentar reducir el tiempo de diagnóstico. Es fácil que después de haber realizado

diferentes experimentos lleguemos a perder la noción de lo que hemos hecho

y repitamos o realicemos experimentos que no tengan ninguna relación con

los resultados obtenidos previamente. Es necesario, pues, que registremos cada

uno de los experimentos realizados.

3.1.3. Corrección

Una vez se ha diagnosticado y encontrado la causa del defecto, entra en juego

su corrección. Toda corrección tiene que implicar las siguientes actividades:

1)�Restablecer�la�situación�inicial. En primer lugar, tenemos que restable-

cer la situación inicial en la reproducción del fallo y eliminar todos aquellos

cambios que se hayan realizado durante la experimentación en el diagnóstico.

Todo el código que hayamos incluido en la experimentación tendría que ser

eliminado.

Es común comentar el código de experimentación o el código que se ha eli-

minado durante la corrección por creer que se podrá necesitar en un futuro.

Este código, que llamaremos "código eliminado comentado", es confuso y pe-

Sistemas de control deversiones

Podemos usar el comparadordel sistema de control de ver-siones (Subversion...) para ana-lizar qué cambios se han intro-ducido entre una versión en laque no existía el fallo y la ver-sión en la que se reproduce elfallo.


ligroso en manos de cualquier programador que desconozca el motivo por el

que se comentó. Se recomienda eliminar siempre el código obsoleto y, en caso

necesario, reubicar este código en un documento de experiencias recogidas.

2)�Implementar�las�pruebas. En este momento podemos aplicar la técnica

del desarrollo guiado por pruebas y crear una prueba que permita reproducir

el fallo.

3)�Realizar�la�corrección. Se tiene que corregir la causa, no el síntoma. Aun-

que pueda parecer obvio, a menudo se realizan cambios que arreglan el sínto-

ma, pero no la causa.

Ejemplo

Supongamos que el pago de las reservas en nuestro aplicativo VCV (A) se realiza mediantela interacción con un sistema externo de pago (B) al que enviamos ficheros en formatoXML y que se dan las siguientes situaciones:

• Por un error, el programador de nuestro sistema ha olvidado incluir el tag de inicio<begin> en el fichero XML que tiene que enviar al sistema de pago.

• Como resultado, el sistema destino no procesa correctamente la petición y se produceun fallo en el sistema A.

• Nuestro programador se pone en contacto con el programador del sistema B paracomunicarle que el sistema de pago no controla bien la situación.

• El programador del sistema externo, bajo presión, y sin considerar los posibles efectos,añade siempre la cadena <begin> en el fichero recibido, lo que permite que nuestrosistema funcione correctamente.

• Poco después, todos los sistemas de las demás compañías que se comunican con elmismo sistema de pago (y ya añadían el tag <begin>) dejan de funcionar.

En este ejemplo se corrigió el síntoma, pero no la causa, que era realmente parte denuestro sistema.

Ved también

En el subapartado 4.5. se ana-liza en detalle la técnica deldesarrollo guiado por pruebas.

4)�Realizar�refactoring�en�el�código. La corrección de un defecto puede abrir

oportunidades de refactoring en el código (por ejemplo, por la posibilidad de

que el código quede más claro y mejor estructurado).

5)�Subir�el�código�al�control�de�versiones. Como último paso, y dentro de

la política establecida para las correcciones (ramas, fusiones, etc.), se subirá el

código fuente al control de versiones.

3.1.4. Gestión del conocimiento y cierre

Nos tenemos que preguntar por qué razones se ha producido el error: ¿eran

ambiguos los requisitos?, ¿se habían definido pruebas para detectar el fallo?,

¿hay alguna librería utilizada que tenga una tasa de defectos grande?, ¿están

los programadores bien formados?

Ved también

En el subapartado 3.3 se es-tudia un poco más en detallequé es el refactoring y por quées necesaria.


Todas estas preguntas responden a la prevención y el aseguramiento de la ca-

lidad, donde tendremos que plantear si hace falta actualizar documentos de

estándares de programación de la organización, actualizar procesos de desa-

rrollo o prever un plan de formación, entre otros.

Finalmente, el programador tendrá que registrar la resolución del defecto en

el informe de la incidencia (cómo se ha corregido, cuál era la causa real, etc.).

3.2. Bitácora

La bitácora12 es un proceso de registro de acontecimientos cronológicos

de lo que hace un sistema o aplicativo durante su ejecución.

(12)En inglés, logging.

En caso de que haya un problema con el aplicativo, este registro será útil para

saber en qué lugar se localiza el defecto, entender su actividad y obtener pistas.

El registro de la bitácora se genera habitualmente sobre la consola de la aplica-

ción (la pantalla) o en ficheros. En programas sencillos de Java, las sentencias

System.out.println o System.err.println nos permiten volcar en la

pantalla (consola) mensajes desde el aplicativo. Esta técnica tiene los siguien-

tes problemas:

• No se eliminan los mensajes temporales registrados. En ocasiones, un pro-

gramador puede mostrar mensajes por la consola que le permitan entender

por qué algo no funciona correctamente, pero después puede olvidar bo-

rrarlos. La consola puede llenarse de detalles superfluos que pueden ocul-

tar los problemas reales.

• Se degrada el rendimiento. No hay ninguna forma sencilla de activar o

desactivar de forma condicional de los mensajes sin recurrir a soluciones

susceptibles de error, como, por ejemplo:

if (DEBUG) { System.err.println("mensaje..." + parámetro);}

• Si usamos la solución anterior no propuesta, tampoco podemos tener un

control esmerado de qué mensajes se tienen que mostrar y cuáles no, aun-

que podríamos incorporar controles del tipo:

If (DEBUG || WARN || ERROR) System.err.println("mensaje..." + parámetro);

• Estamos restringidos a que se vuelquen los mensajes únicamente en los

dispositivos de consola de salida y error. ¿Cómo podemos hacer para vol-

carlos en un fichero rotativo? ¿Cómo podemos volcarlos a la vez en di-

Ejemplo de log

Cuando usamos un progra-ma FTP, este puede generarun fichero de log en el que semuestran la fecha, la hora y lospaths de origen y destino paracada fichero transferido.


ferentes destinos con una única sentencia (tenemos que gestionar cómo

volcar en fichero, cómo enviar un correo de notificación, etc.)?

• El volumen de mensajes no se puede reducir o ampliar, es siempre el mis-

mo para cada petición.

Existen marcos o librerías específicas de bitácora que nos aportan ventajas en el

volcado específico previo, ofreciendo, entre otras, las características siguientes:

1)�Diferentes�niveles�de�bitácora,�lo�que�nos�permite�decidir�si�queremos

volcar�determinados�mensajes�o�no. Por ejemplo, durante la operación de

una aplicación nos puede interesar volcar únicamente acontecimientos rela-

cionados con errores críticos o fatales, pero en desarrollo nos puede interesar

volcar todos los mensajes.

Existe una relación de precedencia entre los niveles, de forma que si se deter-

mina, bien en configuración, bien en tiempo de ejecución, que se vuelquen

los mensajes de un nivel, también se volcarán los mensajes de los niveles su-

periores.

El framework Log4J define por defecto los niveles que se pueden ver en la tabla

siguiente.

Nivel Descripción

Fatal Errores graves que causan una interrupción brusca del sistema

Error Otros errores en ejecución o condiciones inesperadas

Warning Uso de API depreciadas, errores próximos (nos encontramos cerca de consu-mir el 80% de conexiones...) u otras situaciones inesperadas, pero no necesa-riamente malas

Info Acontecimientos de interés (arranque y parada del sistema, por ejemplo)

Debug Información detallada del flujo en el el sistema

Y ofrece una clase principal Logger que incluye los siguientes métodos:

// Métodos de creación y recuperaciónpublic static Logger getRootLogger();public static Logger getLogger(String name);

// métodos para imprimir mensajespublic void debug(Object message);public void info(Object message);public void warn(Object message);public void error(Object message);public void fatal(Object message);

Según el nivel con el que queremos volcar el mensaje, usaremos uno u otro

método (debug, info...). El método habitual para poder mostrar un mensaje

se muestra en el siguiente fragmento:

Enlace de interés

El framework de diario histó-ricamente más reconocido enJava ha sido Log4J, que ac-tualmente es el que se usa yha sido utilizado para desa-rrollar los ejemplos de estemódulo. Podéis encontrarmás detalles al respecto enhttp://logging.apache.org/log4j/index.html.Podéis encontrar tam-bién otros frameworkscomo SLF4J, Logback ojava.util.logging

Depreciar

Cuando se libera una nuevaversión de una librería (API),es posible que partes de ellahayan sido depreciadas (pue-de ser una clase, un métodoo cualquier elemento que yano se necesita). No se eliminanpara evitar problemas de com-patibilidad, pero no se garan-tiza que se eliminen por com-pleto en siguientes versiones.


public class NombreClasse { static Logger logger = Logger.getLogger(this.class); public void funcion() { logger.info(..."); logger.debug(..."); }...

Ejemplo

Si el nivel predeterminado en el fichero de configuración es warning, se volcarán losmensajes escritos con nivel warning (logger.warn(...")), error y fatal, pero ningunode los mensajes con nivel debug e info.

2)�Se�puede�configurar�sobre�qué�salidas�se�tienen�que�volcar�los�mensajes

(fichero, base de datos, correo electrónico, SNMP, consola, sockets...).

Ejemplo

Se puede configurar, por ejemplo, que en el entorno de desarrollo los mensajes se pre-senten por consola y fichero, pero que en el entorno productivo se vuelquen únicamenteen fichero, y que este sea rotativo (cuando supere un determinado tamaño se eliminenlos mensajes más antiguos).

3)�Los�mensajes�pueden�ser�"decorados"�automáticamente�con�otra�infor-

mación�útil (usuario conectado, fecha y hora, clase y número de la línea en

que se ha generado el mensaje, etc.).

Log4J permite, entre otros, los patrones que se ven en la tabla siguiente (se

definen en el fichero de configuración).

Patrón Descripción

%C Mostrar el nombre completo de la clase que ha escrito el mensaje

%d Mostrar la fecha en que se ha escrito el mensaje. Se puede determinar su for-mato completo.Ejemplo: %d{dd MMM yyyy HH:mm:ss,SSS}

%L Número de línea de la clase en la que se ha escrito el mensaje

%m El mensaje que escribe la clase

%M Nombre del método que ha escrito el mensaje

%p Nivel del mensaje (warn...)

Se pueden definir nuevas decoraciones por parte del programador, como, por

ejemplo, que se vuelque información de la sesión y así poder identificar a la

persona que ha sufrido un fallo en concreto.

4)�Capacidad�para�registrar�o�no�registrar�los�acontecimientos�en�un�área

particular, bien en la ubicación lógica del código (un package concreto en

Java), bien en un área funcional.

Appenders

En Log4J el tipo de salida sedetermina con los llamadosappenders, que son clases es-pecíficas que realizan el volca-do en un tipo de salida especí-fica. Por ejemplo, la clase Con-soleAppender permite vol-car por consola, RollingFi-leAppender en un fichero ro-tativo, etc.


Ejemplo

Quiero que se vuelquen los mensajes del módulo A, pero no los del módulo B. Quiero quese vuelquen los mensajes del acceso a la base de datos en un fichero y que, en cambio,los mensajes de la capa de presentación se vuelquen por consola (o en ficheros diferentesal del acceso a la base de datos).

Esta característica se implementa en Log4J con un nombre concreto en el fi-

chero de configuración. Existen tres posibilidades:

a)�Usar�el�rootLogger. La configuración que se especifique en él será de aplica-

ción a todos los mensajes, excepto aquellos que se indiquen en los casos b y c.

log4j.rootLogger=nivel, appender1..., appenderN

b)�Usar�el�nombre�correspondiente�a�un�package. Se puede usar un package

para configurar cómo se quiere volcar todos los mensajes que se generen desde

cualquier clase contenida en dicho package.

log4j.edu.uoc.reservas.puntos =nivel, appender1..., appen-

derN

c)�Usar�un�nombre�específico. En este caso se permite la generación de men-

sajes controlados por el aplicativo en áreas funcionales o lógicas. Su uso se

basa en utilizar la función específica getLogger(nombre).

log4j.nombreespecifico =nivel, appender1..., appenderN

static Logger logger = Logger.getLogger(nombreespecifico);public void funcion() { logger.info(...");

Con este nombre es cómo se determina qué decorador appender y nivel se

tiene que volcar para este nombre.

5)�Se�pueden�automatizar�determinados�tipos�de�acontecimientos. Se pue-

de configurar, por ejemplo, que en el caso de que se dé una excepción que

no hemos controlado con la gestión de excepciones, se envíe un correo al ad-

ministrador.

6)�La�bitácora�se�puede�configurar�en�un�fichero�de�propiedades�o�en�eje-

cución (sin tener que recompilar el código o detener el sistema).

Ejemplo

# Queremos mostrar por defecto todos los mensajes en modo info# o superiores para la consola y para la salida definida en el# AppenderFichero, correspondiente al fichero (ver más abajo).log4j.rootLogger=info, consola, appenderFichero

#A la salida de consola (stdout) configuramoslog4j.appender.consola=org.apache.log4j.ConsoleAppenderlog4j.appender.stdout.consola=org.apache.log4j.PatternLayout


# que aparezca el número de línea, el método.log4j.appender.consola.layout.ConversionPattern=%5p [%t] (%F:%L) -%m%n

# La salida appenderFichero. firme que use RollingFileAppenderlog4j.appender.appenderFichero.=org.apache.log4j.RollingFileAppender# De nombre 'ejemplo.log'log4j.appender.appenderFichero.file=ejemplo.log# Que tiene un tamaño máximo de 100Kb. Si se supera, se eliminan# los mensajes más antiguoslog4j.appender.appenderFichero.maxFileSize=100KB# I en él se decoran los mensajes con un patrón, que difiere del# patrón usado para la salida por consolalog4j.appender.appenderFichero.layout=org.apache.log4j.PatternLayout#mostrar la línea de código, el nombre de la clase y el mensajelog4j.appender.appenderFichero.layout.ConversionPattern= %d{dd- MM-yyyy HH:mm:ss} %L %p %C - %m

# Para los mensajes volcados desde las clases contenidas en el package# 'edu.uoc.hoteles.reservas' se vuelcan los mensajes warn y# superiores (sobreescribe el# nivel por defecto info que se había predeterminado para cualquier# clase arribalog4j.logger.edu.uoc.hoteles.reservas =WARN

Supongamos ahora el siguiente código de la clase que vuelca los mensajes:

package edu.uoc.reservas.vols;public class GestorReservas {

public void reservar() { ... logger.warn("Quedan menos de 5 asientos disponibles en el vuelo" + núm.Vuelo); ... logger.debug("Salimos de la función"); }

Saldría el mensaje siguiente en consola y fichero:

156 WARN edu.uoc.hoteles.reservas.GestorReservas - Quedan menos de5 asientos disponibles en el vuelo 3X34900L

Pero el mensaje "Salimos de la función" no aparecería, ya que se había configurado queel nivel mínimo fuera WARN.

Una vez analizadas las particularidades de la bitácora, tenemos que saber dife-

renciarla de la depuración y averiguar cuándo se tiene que aplicar una u otra:

• La bitácora es más rápida en ejecución que la depuración.

• La bitácora puede ser usada para diagnosticar problemas en el entorno de

producción o en el entorno de desarrollo. La depuración se tiene que usar

en entornos de desarrollo.

• La bitácora es más fácil de ejecutar en entornos distribuidos.

• Si queremos usar la bitácora como una herramienta de depuración, nece-

sitaremos registrar una gran cantidad de acontecimientos poco útiles.

Depuración y bitácora

La depuración es un mecanis-mo para analizar internamen-te el software y poder detec-tar defectos, la bitácora nospermite registrar los aconte-cimientos para obtener infor-mación real de la ejecución delsoftware (datos usados, condi-ciones, etc.).


3.3. Refactoring del código

A medida que se realiza el mantenimiento de un aplicativo (bien para añadir

nuevas funcionalidades, bien para realizar la corrección de un defecto) el códi-

go puede degenerarse. En estos casos es completamente necesario hacer lo que

se llama "refactoring del código"; modificar su comportamiento internamente

aumentando alguna cualidad no funcional (rendimiento, simplicidad, facili-

dad de mantenimiento...) sin modificar su comportamiento externo (aparien-

cia, funcionalidad...).

El refactoring�del�código son los cambios realizados en la estructura

interna del software a fin de que sea más fácil de entender y más barato

de modificar, sin cambiar su comportamiento observable.

El refactoring consigue los siguientes objetivos:

1)�Mejora�el�diseño�del�software. A medida que los programadores hacen

cambios en el código sin un conocimiento exhaustivo de su diseño, el código

pierde su estructura y se hace más difícil entenderlo. Un diseño pobre provoca

que se tenga que codificar más para hacer lo mismo, ya que, a menudo, el có-

digo hace lo mismo en diferentes puntos del aplicativo. Una parte importante

de el refactoring del diseño es eliminar el código duplicado.

2)�Mejora�la�comprensión�del�software. El refactoring del código facilita que

podamos entender el que hemos construido nosotros mismos para ser mejo-

rado y entendido por alguien que en el futuro tenga que hacer cambios en

nuestro código.

3)�Ayuda�a�encontrar�defectos. El refactoring facilita el hallazgo de defectos,

ya que se clarifica la estructura del programa.

4)�Mejora�la�eficiencia�en�la�programación. Sin un buen diseño, el progra-

mador tiene que invertir más tiempo para entender el código y localizar de-

fectos, en lugar de hacer nuevas funciones.

Sin embargo ¿en qué casos tenemos que planificar un refactoring? En sí mis-

ma, el refactoring no es una actividad que tenga que ser planificada, es una

actividad que tiene que ser realizada de forma continuada. El mejor momento

para realizarla es cuando se añade una nueva característica o funcionalidad al

software. En esta situación podemos preguntarnos si hay que hacer un refac-

toring para que sea más fácil entender el código o si es muy complicado rea-

lizar el cambio por cómo está diseñado. Otra gran oportunidad para realizar

un refactoring es cuando se tenga que corregir un defecto o cuando se realiza

una revisión del código.

Comprensión del software

"Cualquiera puede escribir có-digo que un ordenador pue-de entender. Los buenos pro-gramadores escriben códigoque los humanos pueden en-tender".Martin Fowler


Los ejemplos más habituales en los que hay que realizar un refactoring son:

• Código�duplicado. La existencia de código duplicado es una fuente habi-

tual de defectos, ya que provoca que, ante un cambio, se tengan que hacer

modificaciones en paralelo en diferentes puntos del software.

• Métodos�muy�largos. En una programación orientada a objetos, un mé-

todo de más de 25 líneas representa un intento de forzar una programa-

ción estructurada en un modelo orientado a objetos. La solución es usar

la modularidad y descomponer los métodos (agrupando un conjunto de

líneas de código del método en un nuevo método, por ejemplo).

• Clases�muy�largas. Habitualmente, una clase muy larga tiene múltiples

responsabilidades no relacionadas entre sí. Hay que extraer fragmentos de

la clase en una clase o más clases separadas, cada una con una responsa-

bilidad, de forma que entre todas ellas formen un conjunto de responsa-

bilidades.

• Métodos�con�una�lista�larga�de�parámetros. Una lista larga de paráme-

tros hace difícil entender el propósito del método, y cualquier cambio tie-

ne impacto en los que lo usan. Una opción puede ser reemplazar los pará-

metros con la definición de una nueva clase.

• Renombrar�métodos. Los nombres de los métodos tienen que identificar

claramente su propósito. Si se nos hace difícil establecer el nombre de un

método es que este hace más cosas de las que tendría que hacer.

• Reemplazar�valores�literales�usados�en�el�código�por�constantes (a este

caso se lo denomina números mágicos).

Riesgos de modificaciónsobre código duplicado

Podemos olvidar hacer el cam-bio en algún punto o nos pue-de ser difícil reconocer encuántos puntos se encuentra elmismo código.


Ejemplo

Supongamos el siguiente fragmento de código de nuestro sistema VCV, en el que se haceel cálculo de la ruta óptima desde el aeropuerto origen al aeropuerto destino escogidospor el usuario:

public class GestorRutas { public void calcularRutaOptima(String anAeropuertoOrigen, String anAeropuertoDestino){ ... distanciaKm = 0.62f * distanciaMillas; System.out.println("Distancia en km": + distanciaKm); ... }}

Donde tenemos una transformación de millas en kilómetros, que, además, se usa en otrospuntos del software. El refactoring del código consiste en extraer el valor en una constanteque pueda reutilizarse en otras partes del sistema y, además, facilite su mantenimiento:

public class GestorRutas { private static final float CONVERSION_MILLAS_KILOMETROS = 0.62f;

public void calcularRutaOptima(String anAeropuertoOrigen, String anAeropuertoDestino){ ... distanciaKm = CONVERSION_MILLAS_KILOMETROS * distanciaMillas; System.out.println("Distancia en km": + distanciaKm); ... }}

Existen algunos casos en los que no estará justificado que realicemos un refac-

toring. Si el coste de refactoring es muy alto, el código de todo el aplicativo está

muy desestructurado o el impacto de las modificaciones tiene un alto riesgo,

puede ser conveniente plantear la construcción desde cero del código.

Herramientas con apoyo alrefactoring del código

La mayoría de las herramientasde desarrollo, como, por ejem-plo, Eclipse, dan apoyo al re-factoring del código.


4. Técnicas de prevención de defectos

Las pruebas y revisiones se basan en encontrar fallos o defectos que ya han

sido introducidos en el software y se tienen que localizar y corregir posterior-

mente, pero su esfuerzo se puede reducir si se establecen técnicas que eviten la

aparición de defectos. En este apartado analizaremos algunas de estas técnicas.

4.1. Análisis de causa raíz

El análisis de causa raíz se basa en analizar los defectos encontrados

para determinar su causa, adoptar las acciones necesarias para prevenir

errores similares en el futuro y borrar defectos parecidos que puedan

existir en el sistema o detectarlos lo más pronto posible en el desarrollo

(con revisiones, por ejemplo).

Estándares en la prevención de defectos

Existen dos técnicas o estándares reconocidos en la prevención de defectos: el failuremodes and effect analysis (FMEA) y el fault tree analysis (FTA). El primero está enfocado aidentificar los fallos potenciales, mientras que el segundo está enfocado a las causas deestos fallos.

Una de las técnicas más útiles para analizar los defectos se basa en el principio

de Pareto, según el cual, el 80% de los problemas se pueden corregir con el

20% del esfuerzo. Si nos concentramos en explorar los defectos más habituales

de mayor severidad (el 80%), podremos obtener una ganancia sustancial si

actualizamos el proceso para prevenirlos.

http://www.fmea-fmeca.com/

http://www.fmea-fmeca.com/

http://www.faulttree.org/


Ejemplo

Imaginemos que hemos clasificado los defectos encontrados en unas pruebas del sistemaVCV según su tipo, tal como se muestra en la tabla siguiente.

Tipo de defecto Número de defectos

Interfaz 45

Gestión�de�datos 32

Computación 15

Mejora 9

Lógico 4

Datos 3

Calidad�documentación 3

Documentación 2

En el ejemplo, el 80% de los defectos (ved la serie Acumulado en el gráfico de arriba) sondefectos de interfaz, gestión de datos y computación. Con este sencillo análisis podemosestablecer fácilmente que hace falta una mejora en la prevención de este tipo de defectos.

También será importante conocer en qué puntos del ciclo de vida se introdu-

cen más defectos, y adoptar acciones de mejora en los procesos y recursos (con

formación, herramientas, etc.).

4.2. Educación y formación

La educación y formación de los equipos de desarrollo de una organización

puede ayudar a prevenir la inyección de determinados defectos.


Ejemplo

Muchas veces se malgasta memoria de procesamiento por haber usado en el código untipo de datos que ocupa mucho espacio pero no es necesario. En nuestro programa delCVC usamos una variable de tipo int de Java para almacenar el número de adultos de lareserva, para el que solo queremos representar 2 dígitos. El tipo int permite representardesde el valor –2.147.483.648 hasta el 2.147.483.647. Lo correcto es usar el tipo byte,que permite representar valores entre –128 y 127 y, por tanto, cubre nuestras necesidades.

4.3. Guías y estándares de programación

Un estándar de programación es un conjunto de reglas o guías definido

por la organización, que recomienda y/o obliga a un estilo de progra-

mación y la utilización de prácticas o métodos para cada tipo de pieza

de software escrito en un lenguaje en particular.

Los estándares de programación se diseñan, en general, para hacer que el có-

digo sea más fácil de mantener y lo pueda entender cualquier integrante del

equipo o cualquier externo al equipo, y para animar buenas prácticas de pro-

gramación. Su implantación aporta los siguientes beneficios:

• Incrementa�la�transferibilidad�del�código. Al forzar la necesidad de es-

tructurar mejor el código e incluir comentarios, el software podrá ser trans-

ferido a un equipo nuevo con menos coste.

• Menos�defectos�en�el�código. Una buena estructura del código permite

que los programadores tengan más facilidad para ver qué errores cometen.

• Facilidad�de�prueba. Un código bien estructurado hace más fácil diseñar

las pruebas (con técnicas de caja blanca).

• Facilidad�de�mantenimiento. Si se sigue un estilo idéntico en la progra-

mación de los componentes, les será mucho más fácil y rápido a otros pro-

gramadores modificar un código que no han hecho ellos.

¿Qué tipo de reglas se definen en un estándar de codificación? Entre otras, se

definen las siguientes categorías:

• Nombres de los ficheros y organización

• Convenciones de nombre

Ejemplo

Se determina en la programación del sistema VCV que todas las clases de presentacióntendrán que contener el sufijo "vista" (ReservaVista) y que los nombres de los packagestendrán que cumplir el patrón edu.uoc.nombreaplicacion.nombremodulo".

Convenciones de código

Las convenciones de códigono pueden ser verificadas au-tomáticamente por el compila-dor, pero sí por herramientasde análisis estático de código.


• Aspectos de indentación y espacios en blanco

• Tamaño de los diferentes elementos (clase, función...). Por ejemplo, una

función no puede tener más de 25 líneas.

• Comentarios de código

• Declaraciones y sentencias

• Buenas prácticas de programación

Buenas prácticas deprogramación

Algunos ejemplos de buenasprácticas de programaciónson no usar el operador "="para comparar, usar siempre"equals" en su lugar, no utilizarnúmeros mágicos, etc.

Si bien es cada organización quien ha de definir sus guías y estándares de pro-

gramación, existen algunos ejemplos ya disponibles en los que nos podemos

basar.

El uso de buenas prácticas de programación disminuye la necesidad de realizar

costosos refactoring en el código.

4.4. Validación de los datos

Los usuarios se equivocan. Si bien el software tiene que dar indicaciones de

cuáles son los formatos válidos para una entrada, ha de controlar que no se

introduzcan valores incorrectos.

La comprobación o validación de las entradas se tiene que realizar desde dife-

rentes puntos:

Enlace de interés

Se recomienda acceder a lasconvenciones y buenas prác-ticas de programación queOracle propone en:http://www.oracle.com/technetwork/java/code-conv-138413.html

Robustez

Como el programa valida ycontrola los datos, es parte delfactor de calidad de robustez.

• Datos de usuario (introducidos por pantalla). Hay que comprobar, por

ejemplo, que los números estén dentro de su rango permitido y no se reali-

ce ningún ataque de seguridad.

• Datos intercambiados con sistemas externos.

• Datos internos de una función. La comprobación de los valores de los pa-

rámetros de entrada en una función es equivalente a cualquiera de los

otros tipos, pero, en este caso, los datos vienen de otra función del mismo

programa.

En todos los casos, cuando los datos de entrada sean inválidos se tendrá que

adoptar una medida de reacción, aplicando una o más de las siguientes op-

ciones:

• Sustitución por datos válidos. En el caso de recorrer un conjunto de da-

tos, tenemos que tomar la decisión de abortar o, bien, continuar con el

siguiente dato válido.

Inyección de sentenciasSQL

Uno de los ataques de segu-ridad más habituales es la in-yección de sentencias SQL encampos de entrada que no sevalidan correctamente por elsoftware.

http://www.oracle.com/technetwork/java/codeconv-138413.html




Ejemplo

En el sistema VCV queremos procesar cada noche todas las reservas realizadas y enviarlasa la central de reserva de vuelos de las compañías. Si en el procesamiento detectamosque una reserva es errónea por algún motivo, ¿abortamos y no enviamos ninguna de lasreservas o descartamos la reserva errónea y enviamos las restantes? Seguramente consi-deraremos esta última opción como la más recomendada.

• Almacenar un mensaje de error en un fichero interno (con bitácora).

• Devolver un código de error.

• Mostrar un mensaje de error para cualquier error encontrado.

Para controlar los datos inválidos que vengan del propio sistema usaremos las

aserciones o diseño por contrato, como veremos a continuación.

4.4.1. Diseño por contrato

El diseño o programación por contrato prescribe cómo se tienen que

definir formalmente los componentes de software, incorporando a sus

funciones tres conceptos:

• Precondiciones. El método cliente que invoca una función tiene

que proporcionar una entrada correcta (obligación). El método des-

tino no ha de controlar ningún caso especial, excepto la precondi-

ción.

• Poscondiciones. Garantizan el resultado si el cálculo de la función

es exitoso.

• Invariantes. Mantienen una propiedad de entrada en su salida.

Muchos lenguajes proporcionan facilidades para realizar cualquiera de estos

tres tipos de aserciones. En Java también existe este soporte con la sentencia

assert. Las aserciones son una expresión booleana que, en caso de ser eva-

luada como falsa, indica un defecto en el código.


Ejemplo

Supongamos la función de cálculo de puntos de fidelización del sistema VCV. Esta fun-ción es llamada internamente a partir de los datos introducidos previamente por el usua-rio. La función espera que le llegue un número de adultos superior a 0 e inferior a 50(quien lo haya validado previamente tendría que ser la capa de presentación), por lo quese usa una aserción para verificarlo.

private int calcularPuntos(byte aNumAdultos){ assert aNumAdultos>0 && aNumAdultos<50: Número de adultos": + aNumAdultos;

...}

Si el parámetro aNumAdultos es mayor que 50 o menor que 0, saldrá un error del tipoAssertionError (aparecerá por pantalla).

Las aserciones permiten detectar de forma preventiva defectos de programa-

ción en el desarrollo. Son usadas para depurar errores lógicos en la aplicación.

Por defecto están desactivadas cuando se ejecuta el software, ya que pueden

impactar en el rendimiento y son innecesarias para el usuario.

Nunca usaremos las aserciones para controlar excepciones de entradas recibi-

das en una función pública, y se tendrían que desactivar antes de que el apli-

cativo se ponga en producción.

Gestión de excepciones Aserciones

Tratamiento de circunstancias inusuales du-rante la ejecución del programa. Robustez.

Asegurar que el software es correcto.

No hay que desactivarlas nunca. Pueden ser desactivadas en el arranque de lamáquina virtual.

No se tienen que usar en la comprobación deargumentos en funciones públicas.

4.5. Desarrollo guiado por pruebas

Activación de lasaserciones

Si se quiere activar las asercio-nes en Java, se tiene que arran-car la máquina virtual Java conel parámetro -ea (java -ea...).

El desarrollo guiado por pruebas es una técnica específica, aplicable a

cualquier ciclo de vida, en la que antes de escribir el código del compo-

nente se escriben sus casos de prueba unitarios.

Con esta técnica se consigue un diseño más robusto (en el caso de un cambio

incorrecto en el componente, lo detectamos rápidamente con la prueba) y que

el código del componente sea más claro, funcional y fácil de mantener.

Sin embargo ¿cómo podemos crear una prueba si todavía no existe el compo-

nente? Veamos cuál es el proceso de esta técnica:

Terminología

El desarrollo guiado por prue-bas se llama en inglés test dri-ven development. Se encuen-tra definido en la metodolo-gía ágil para el desarrollo desoftware denominada extremeprogramming (XP), pero puedeaplicarse en cualquier metodo-logía.

Clean code that works

En inglés, el objetivo de conse-guir un código claro y funcio-nal se resume en la frase cleancode that works.


1) Primero se escribe el caso de prueba que tiene que comprobar una propiedad

concreta de un componente.

2) El componente todavía no existe, por lo que tenemos que crear su esqueleto

sin contenido y escribir la función que se quiere probar poniendo un resulta-

do fallido, pero sin escribir ningún código más (la función solo incluye una

sentencia de retorno de un resultado prefijado no esperado).

3) A continuación se ejecuta el caso de prueba para comprobar que se da el

fallo (resultado negativo).

4) Se escribe el mínimo código en la función del componente para devolver

el resultado esperado por la prueba.

5) Se vuelve a ejecutar la prueba para comprobar que es satisfactoria.

6) Finalmente, y de forma iterativa se realiza un refactoring del código a medida

que se van construyendo los diferentes casos de prueba sobre el componente.

Ejemplo

En el ejemplo que se muestra en la siguiente figura, se realiza un caso de prueba conJUnit para verificar el correcto funcionamiento de la función de cálculo de los puntosde fidelización del sistema VCV.

4.6. Reutilización

La reutilización de software es un método clave para incrementar la calidad del

software y la productividad en el desarrollo. Habitualmente, si reutilizamos

componentes que ya han sido probados previamente reduciremos el número


de defectos. Eso se puede aplicar a la utilización de marcos de trabajo (frame-

works) y librerías ampliamente extendidas, en los que hay una gran comuni-

dad que se dedica a corregir defectos de forma continua.

Ahora bien, para poder ser eficientes, la organización tiene que definir un pro-

grama sistemático de reutilización que permita medir su progreso, identificar

estrategias y establecer un plan de comunicación para facilitar el acceso a los

elementos reutilizables. Tenemos que considerar que la reutilización se pue-

de aplicar a cualquier entregable, no solo a fragmentos de código fuente sino

también a documentos de requisitos, estructuras de diseño, datos, casos de

prueba, interfaces, etc.


5. Técnicas de tolerancia a fallos

Las técnicas de tolerancia a fallos permiten reducir el efecto de un fallo

mediante su gestión y recuperación.

La complejidad y el tamaño de los sistemas hacen que sea imposible probarlo

todo, y las actividades de calidad previas no pueden eliminar por completo

todos los defectos, por lo que algunos se pueden quedar sin corregir. Si se

da un fallo ¿tenemos algún medio para que se reduzca su efecto y no afecte

al entorno del sistema? La respuesta es afirmativa, ya que existen diferentes

técnicas que permiten que los sistemas sigan funcionando incluso en el caso

de que surjan fallos en el software o en el entorno en que se ejecuta.

Sistema eléctrico de seguridad

Estas técnicas se usan en la vida cotidiana desde hace mucho tiempo. Si la corrienteeléctrica de un hospital falla, se pone en marcha otro sistema eléctrico de seguridad (deotra compañía o de un generador propio, por ejemplo).

Cualquier técnica de tolerancia a fallos incluye cuatro fases: la detección del

fallo, la generación de la excepción, su gestión y la recuperación. En este apar-

tado analizaremos de forma práctica estas fases considerando el lenguaje de

programación Java.

5.1. Detección del fallo

La detección de un fallo tiene lugar en el momento en que un componente

efectúa una operación y obtiene un resultado inesperado. En algunos casos,

este resultado puede producirse por comprobaciones de tiempo o de restric-

ciones en tiempo de ejecución.

Las comprobaciones de tiempo se basan en iniciar un temporizador en el mo-

mento en que se solicita un servicio a un componente. Este temporizador ex-

pira en el momento en que se espera que un servicio haya finalizado. Si acaba

antes de tiempo se cancela y se considera que ha habido un fallo.

Ejemplo

Nuestro aplicativo VCV se comunica con un componente externo de un banco para rea-lizar el pago mediante un servicio web. Una vez enviada la petición al servicio web, es-peramos un máximo de tiempo para determinar si ha habido algún fallo en el destino.


En las comprobaciones de restricciones en tiempo de ejecución se verifica que

no se hayan excedido determinadas restricciones, como valores frontera o va-

riables. Cada vez que se modifican las estructuras de datos asociadas a estas

variables se comprueba si hay alguna inconsistencia.

Ejemplo

Podemos verificar si el número de accesos al sistema VCV es superior al previamente con-figurado para enviar a estos accesos un aviso de "Vuelva a intentarlo en unos minutos".

5.2. Generación de la excepción

Listeners

Listeners es un mecanismo enJava que permite ser notificadode cualquier modificación enun dato y así comprobar si seestá desbordando.

Una vez se ha detectado una situación real de fallo, se lanza una excepción

para indicar que algún componente tendrá que gestionarla y tratarla.

La excepción es el acontecimiento anormal que tiene lugar durante la

ejecución de una rutina o función y es efecto de un fallo.

Durante la interacción entre dos componentes podemos encontrar los siguien-

tes escenarios:

1) Un componente B recibe una petición inválida desde otro componente A.

El componente receptor B genera una excepción hacia el componente que lo

ha llamado (excepción de interfaz).

2) El componente A llama a un componente B del que ha recibido una excep-

ción (bien de interfaz, bien por un fallo). El componente A activa su gestión

de excepciones, en la que tendrá que determinar si continúa con su actividad

normal o lanza una nueva excepción al componente superior en la cadena

que lo ha llamado (excepción fallida).

Ejemplo de excepción

El propio lenguaje y algunoscomponentes lanzan una ex-cepción cuando detectan si-tuaciones anómalas.


3) Durante la actividad normal del componente A, detecta un fallo propio y

genera una excepción que es tratada por su gestor de excepciones (excepción

local).

En Java, las excepciones son generadas con la sentencia throw new Nom-

breExcepcion. El método que incluya esta sentencia tiene que incluir asi-

mismo al final de su definición la cláusula throws NombreExcepcion.

public void tratarFidelizacion(String aNombreCliente...) throws FidelizacionException {

if (...) {

throw new FidelizacionException("El cliente "+ aNombreCliente + no tiene...");

}

...

El lenguaje Java permite generar dos tipos de excepciones: excepciones de ti-

po controlado (checked) o excepciones de tipo no controlado (unchecked).

Estos tipos determinan respectivamente si la excepción tiene que ser tratada

obligatoriamente o no por algún gestor de excepciones.

Podemos crear excepciones específicas en una aplicación que deriven de estajerarquía base o indirectamente de clases que se encuentren por debajo deesta jerarquía (ya existentes en frameworks que usamos, librerías, excepcionesespecíficas del lenguaje, etc.).

Las excepciones�de�tipo�controlado representan excepciones "no fatales" en

la ejecución del programa, que tienen que ser tratadas en el código que recibe

la excepción o, bien, obviadas y transmitidas al siguiente objeto en la cadena

de llamadas iniciada. Para crear una excepción de este tipo se tiene que heredar

de la clase Exception.


Ejemplo

El componente de reservas del sistema VCV, una vez finalizada la reserva, envía al correoelectrónico del usuario un billete electrónico que permite realizar el check-in de forma ágil.Al comunicarse con el componente que hace el envío, recibe una excepción indicandoque el correo de destino no existe. Sin embargo, este componente toma la decisión de nogestionar la excepción y la pasa a la clase anterior que lo ha llamado. Si no es controladapor ninguna de las clases en la cadena de llamadas, llegará a la pantalla del usuario.

Dentro de las excepciones de tipo no controlado podemos diferenciar dos sub-

tipos:

1)�Error. Excepción considerada fatal por la ejecución del programa. Son ex-

cepciones externas a nuestro programa.

Ejemplo de error

Un ejemplo de error es cuando al escribir un fichero en un directorio hay un problemade red y el propio sistema nos da una excepción de tipo IOException.

2)�RuntimeException. Representan condiciones excepcionales internas a la

aplicación, que esta no puede anticipar. En general corresponden a defectos

de programación, como el uso incorrecto de la API o errores lógicos.

Ejemplo de RuntimeException

Nuestro sistema VCV pasa a una función interna un objeto no inicializado (nulo) querepresenta al cliente que ha hecho la reserva. La función que lo recibe no compruebasi el objeto es nulo e intenta acceder a uno de sus atributos. El lenguaje, al detectar es-ta situación, genera automáticamente una excepción de tipo NullPointerException(heredada de RuntimeException).

Todas las clases anteriores heredan de la clase padre Throwable. En general,

las clases de excepción de nuestro aplicativo siempre heredarán directamente

de Exception.

5.3. Gestión de la excepción

Los gestores de las excepciones son los encargados de recibir las excepciones

y determinar cuáles son las acciones que se tienen que adoptar para mitigar

el fallo.

En Java, si un componente A llama a una función de un componente B, que

declara la generación de una excepción BX (throws BX), puede determinar:

1) No hacer nada con ella y dejarla pasar hacia el componente superior que lo

ha llamado inicialmente. En este caso tendrá que añadir el tipo de excepción

(BX) que puede recibir a la lista de excepciones lanzadas por el método del

componente que recibe la excepción.

Ejemplo

public void tratarFidelizacion(...) throws FidelizacionException, Ex-cepcionInferior

Nota

Las excepciones de tipo nocontrolado no tienen que sercapturadas o gestionadas obli-gatoriamente por nuestro có-digo.


2) Tratar la excepción. En este caso tiene que usar las sentencias de bloque

try-catch-finally.

public void hacerReserva(String aNombreCliente...) throws NullPointerException {

...

try {

tratarFidelizacion(aNombreCliente)

...

} catch (FidelizacionException) {

...

} finally {

...

}

}

Dentro del bloque try se tienen que incluir todas las funciones que puedan

generar una excepción (porque lo dice su cláusula throws).

Si dentro del código del try podemos recibir diferentes tipos de excepciones,

tendremos que crear un catch para cada tipo de excepción que se pueda re-

cibir. En estos bloques es donde realizaremos el tratamiento de la excepción,

bien lanzando una nueva excepción (throw), bien continuando con la activi-

dad normal.

Por último, el bloque finally recoge aquello que haremos independiente-

mente de que se haya producido o no una excepción. Eso puede ser usado para

liberar recursos que se han asignado al bloque try.

La gestión de excepciones se debe realizar de forma adecuada, tomando las

siguientes pautas:

1) Se tiene que lanzar una excepción para condiciones que son realmente ex-

cepciones y no pueden ser gestionadas con otras prácticas de codificación (bi-

tácora...).

Finally

El bloque finally siempre seejecuta, tanto si ha habido al-guna excepción como si no,incluso si dentro del código dealgún catch se llama a algunafunción que genera de nuevouna excepción.


2) Se tiene que evitar relanzar hacia los niveles superiores las excepciones re-

cibidas. Si una condición de error se puede gestionar localmente, hacerlo.

3) Se tienen que generar las excepciones en un nivel adecuado de abstracción.

No tiene sentido lanzar una excepción de acceso a base de datos en un método

de nivel superior de negocio.

4) Se tiene que evitar el uso de bloques catch sin código. No se tiene que

ignorar el tratamiento de las excepciones.

5) Se tienen que incluir en el mensaje de la excepción las circunstancias reales

que han provocado la excepción.

Ejemplo

Si al reservar un vuelo en el sistema VCV se ha dado una excepción en la generación deltique, informar en la excepción de cuál es el dato concreto que ha provocado el error,tanto para una gestión interna como para presentar al usuario indicaciones de cuál hasido el problema.

En Java, las excepciones que no tratamos en ningún gestor de excepciones de

nuestro código son finalmente tratadas por un gestor de excepciones superior

de la máquina virtual de Java, que toma como única decisión la de volcar por

pantalla la información de la excepción producida.

Ejemplo

En nuestro sistema VCV, el último paso de la reserva incluye un campo con datos de latarjeta de pago. Al aceptar los datos se envía la información de pago a un sistema externoo pasarela de pago que comprueba el saldo de la tarjeta y efectúa el cobro.

Si esta pasarela está caída y no gestionamos la excepción, el sistema mostraría finalmentepor pantalla un mensaje como el que aparece a continuación:


Este mensaje, como se puede comprobar, no es comprensible para el usuario final, quienno puede realizar ninguna acción para abrir una incidencia, y da incluso informaciónque podría ser usada por algún atacante (URL del servicio web). En cambio, si se gestionala excepción correctamente, se podría mostrar un mensaje como el siguiente:

5.4. Recuperación

Dentro de la gestión de la excepción se tiene que tomar una acción de recu-

peración, bien de forma estática, bien dinámica. La recuperación estática se

basa en devolver al componente a un estado predeterminado, ya sea el inicial

o uno de los posibles estados.


Ejemplo

Durante la finalización de la reserva de un vuelo en el sistema VCV se pierde la conexióncon el sistema de pago y el sistema determina cerrar la sesión del usuario y que este vuelvaa iniciar de nuevo la reserva.

La recuperación dinámica utiliza puntos de control que son instantáneas del

estado que pueden ser creados en diferentes puntos de la ejecución, bien a

intervalos fijados en el tiempo, bien en específicos puntos de la ejecución.

Ejemplo

En el mismo caso anterior, durante la ejecución de la reserva el sistema almacena el estadode la misma y sus datos. Cuando tiene lugar el fallo, el sistema reenvía al usuario al últimopunto en que se había quedado.

Sin embargo, hay acciones que no se pueden recuperar o deshacer. En estos

casos se tiene que tomar en consideración cuál debe ser el orden para incluir

al final de la secuencia de acciones la acción que no tenga marcha atrás.

Ejemplo

Supongamos que el sistema VCV envía primero un correo electrónico para confirmar lareserva y, a continuación, un SMS, pero que este último falla. El correo ya habrá sidoenviado y no se podrá deshacer una acción que no tiene marcha atrás (el SMS no se hapodido enviar, pero sí se ha enviado el correo electrónico).


6. Herramientas

El uso de herramientas permite incrementar la eficiencia y efectividad de los

diferentes procesos, actividades y técnicas que hemos visto en el módulo.

En este apartado nos basaremos en la estructura de las herramientas que, según

el tipo de perfil al que van dirigidas, se clasifican en herramientas de gestión

de las pruebas (gestores), herramientas de definición y diseño de pruebas (ana-

listas de pruebas), herramientas de ejecución de pruebas dinámicas (probado-

res), herramientas de ejecución de pruebas estáticas (revisores) y herramientas

específicas para desarrolladores.

Por último, veremos herramientas de soporte que, si bien no se pueden iden-

tificar como herramientas dirigidas a ninguno de los perfiles anteriores, son

imprescindibles para la consecución de los hitos establecidos.

6.1. Herramientas de gestión de las pruebas

Las herramientas de gestión nos permiten realizar las tareas asociadas a la ges-

tión del ciclo de las pruebas, como el análisis de riesgos, la estimación de los

esfuerzos, la planificación de las pruebas y su monitorización. Aportan, entre

otras, las siguientes funcionalidades:

• Planificación de las pruebas, seguimiento de su ejecución (horas invertidas

en cada actividad, persona que las tiene que ejecutar, etc.) y riesgos.

• Gestión de la documentación de las pruebas: especificaciones de prueba,

procedimientos y establecimiento de la trazabilidad de las pruebas con los

requisitos (qué requisitos cubre cada prueba).

• Seguimiento de la ejecución de las pruebas: pruebas planificadas, especifi-

cadas, ejecutadas, pasadas con éxito y fallos.

• Registro y seguimiento de los defectos encontrados durante las pruebas.

• Generación de informes y métricas (tendencias de defectos corregidos

frente a creados, número de casos de prueba, etc.).

• Comunicación y visión integrada con otras herramientas:

– Ejecución de las pruebas (para visualizar el estado de las pruebas).

– Herramientas de gestión de incidencias (para extraer información de

las incidencias y hacer su seguimiento).

Ejemplos de herramientasde gestión de las pruebas

Los siguientes son ejemplos dealgunas herramientas de ges-tión de las pruebas: RTH (gra-tuita), XQual-XStudio Testo-pia (extensión de Bugzilla), HPQuality Center, IBM RationalTestManager o SilkCentral TestManager.


– Herramientas de gestión de la configuración (para controlar los activos

de pruebas generados).

– Herramientas de gestión de requisitos (para poder establecer la traza-

bilidad de las pruebas con los requisitos).

Ejemplo de la herramienta RTH, que permite gestionar los requisitos y pruebas de unaaplicación

6.2. Herramientas de diseño y preparación de datos de las

pruebas

Las herramientas de diseño de pruebas ayudan a la creación de las especifi-

caciones de prueba. Algunas de estas permiten la creación de diagramas y la

generación de documentación de casos de prueba, pero otras son capaces de

generar casos de prueba de alto nivel a partir de los requisitos o de un modelo

(creado, por ejemplo, con UML).

Ejemplo

En la siguiente figura se muestra cómo se han diseñado los casos de prueba del sistemaVCV con clases de equivalencia, mediante la herramienta CTE, gratuita.

Ejemplos de herramientas

Algunos ejemplos en el merca-do que pueden generar casosde prueba son:• Conformiq Qtronic• Microsoft Spec Explorer• Smarttesting Test Designer

http://www.berner-mattner.com


Preparar un juego de datos de prueba puede comportar un gran esfuerzo, espe-

cialmente si queremos generar un conjunto grande de datos. Las herramientas

de preparación de datos dan soporte a esta necesidad, permitiendo la selección

de fuentes de datos (una base de datos existente, un fichero XML...), la crea-

ción y generación de datos y su manipulación.

Algunas de estas herramientas permiten seleccionar datos reales ya existentes

(de una base de datos de producción, por ejemplo) y transformarlos automá-

ticamente en otros, ocultando datos sensibles (por ejemplo, los NIF son cam-

biados por NIF no reales, los nombres son intercambiados, etc.). Este proceso

se denomina habitualmente "enmascaramiento de datos" y permite la ejecu-

ción de pruebas con datos reales y simular así el máximo de condiciones de

prueba posibles.

Es especialmente importante poder generar diferentes volúmenes de datos

"reales" en pruebas de rendimiento, en las que se requiere la ejecución de di-

ferentes usuarios con diferentes datos.

6.3. Herramientas para la ejecución de pruebas dinámicas

Las herramientas de ejecución de pruebas dinámicas son utilizadas principal-

mente para la realización de pruebas de regresión basadas en la automatiza-

ción de las mismas. Permiten la ejecución de procedimientos de prueba más

rápidamente y con más garantías que si lo hiciera una persona.

Ejemplo

¿Cómo podríamos simular la interacción de 1.000 alumnos a la vez sobre la web del sis-tema VCV si no disponemos de usuarios reales que lo prueben? Podríamos reunir a 250personas interinas que abrieran cuatro navegadores a la vez y, mientras fueran navegan-do, tuvieran que registrar en cada uno de ellos los tiempos de respuesta obtenidos encada interacción y se hubieran de recoger y analizar los datos por cada pantalla anotada,etc. Para suplir estas problemáticas, una herramienta de ejecución de pruebas puede serde gran ayuda.

Herramientas degeneración de datos deprueba

Algunos ejemplos de herra-mientas de generación de da-tos de prueba son: Grid-toolsDatamaker, Datanamic DB Da-ta Generator y Microfocus Da-ta Express.

Enmascaramiento dedatos

El enmascaramiento de datoses obligatorio cuando tenemosque usar datos sensibles en laspruebas. Hay datos que, por suconfidencialidad, no puedenser conocidos.


6.3.1. Automatización de las pruebas

Las herramientas de ejecución de pruebas trabajan generalmente de acuerdo

con un conjunto de instrucciones escritas en un lenguaje de scripting perso-

nalizado por la herramienta. Con este lenguaje, el probador puede establecer

cuáles son las acciones que tendrá que realizar la herramienta contra el aplica-

tivo que se quiere probar13 y qué resultados tendrá que verificar automática-

mente (mirar que aparezca el mensaje 'Vuelo reservado con éxito', que el lis-

tado de vuelos muestre los vuelos esperados por un usuario en concreto, etc.).

Para facilitar la tarea de programación, estas herramientas suelen ofrecer la

posibilidad de grabar y reproducir14 una navegación real contra la aplicación.

El probador indica a la herramienta que empieza una grabación, accede a la

aplicación y realiza las diferentes acciones que quiere probar. A medida que se

realiza la interacción del probador con el aplicativo, la herramienta va gene-

rando, para cada acción, la sentencia correspondiente en el lenguaje de scrip-

ting. Adicionalmente, el probador puede marcar en la pantalla de la aplicación

qué es lo que se quiere validar en cada prueba y la herramienta lo registra.

En el momento de la ejecución automática, la herramienta realizará la inter-

acción con la aplicación como si se tratara de un usuario real, siguiendo las

sentencias del script, comparando los resultados esperados con los reales y ge-

nerando el resultado final de la prueba (ha sido fallida, ha pasado, en base a

que las condiciones y resultados son los que se esperaban).

Las características de estas herramientas permiten:

• Capturar las entradas de prueba realizadas manualmente.

• Almacenar los resultados esperados en una pantalla u objeto (un tag con-

creto HTML, un mensaje, etc.) para poder ser comparados la próxima vez

que se ejecute la prueba.

• Ejecutar las pruebas a partir de los scripts almacenados y los datos que se

hayan indicado.

• Comparar en la ejecución los resultados esperados y los reales.

• Registrar las resultados de las pruebas (han pasado, han fallado, etc.) y

enviarlos a la herramienta de gestión de pruebas.

(13)Por ejemplo, acceder a la URLhttp://www.uoc.edu/reserves,apretar el botón "Quiero reservarun vuelo", escoger el aeropuertode origen "Barcelona", etc.

Lenguaje de scripting

Un lenguaje de scripting es unlenguaje de programación quepermite el control de una omás aplicaciones. Este lengua-je es diferente del lenguaje enque está escrita la aplicación.

(14)La funcionalidad de la herra-mienta para grabar y reproducir sellama capture & replay en inglés.

http://www.uoc.edu/reserves


6.3.2. Herramientas para la ejecución de pruebas unitarias e

integración

Para la ejecución de pruebas unitarias y de integración, la herramienta más

utilizada en el entorno Java es JUnit. TestNG también es otra opción seria

que aporta algunas funcionalidades más que JUnit, pero que todavía no la ha

desbancado como estándar de facto.

Diferentes herramientas de soporte nos permitirán visualizar los resultados de

las diferentes pruebas unitarias y ver cuáles han fallado (por ejemplo, porque

un cambio erróneo en el código haga que el resultado real no sea el esperado).

6.3.3. Herramientas para la ejecución de pruebas de sistema

Dentro de las herramientas para la ejecución de pruebas de sistema pode-

mos distinguir las siguientes herramientas: herramientas de ejecución de prue-

bas funcionales, herramientas de ejecución de pruebas de rendimiento, herra-

mientas de ejecución de pruebas de seguridad y herramientas de ejecución de

pruebas de accesibilidad.

Herramientas de ejecución de pruebas funcionales

Enlaces de interés

Para saber más sobre TestNGy JUnit podéis accedera http://www.junit.org/y http://testng.org/doc/index.html

Las herramientas de ejecución de pruebas de sistema funcionales son el ejem-

plo más claro de automatización para grabación y reproducción.

Sellenium

Sellenium es un ejemplo de herramienta gratuita de automatización de pruebas funcio-nales que se integra con otras herramientas de software libre. Permite la grabación desdeun navegador Firefox de una navegación e indicar qué resultados se quieren comprobardurante las pruebas automáticas.

Herramientas de ejecución de pruebas de rendimiento

Las herramientas de ejecución de pruebas de rendimiento permiten generar

volúmenes grandes de carga en la aplicación y medir su rendimiento en dife-

rentes escenarios. Están formadas por dos elementos principales: un generador

de carga y un componente de análisis.

Diversas herramientas

Si bien existen muchísimas herramientas de pruebas de rendimiento destacamos las si-guientes:

• JMeter (gratuita, ampliamente usada en software libre)• OpenSTA (gratuita)• Grinder (gratuita)• HP LoadRunner• Compuware QALoad• IBM Rational Performance Tester• Microfocus SilkPerformer

La generación de carga se realiza en tres fases:

Otras herramientas

Otras herramientas de auto-matización funcional amplia-mente conocidas son:• Fitnesse (gratuita)• Microfocus SilkTest• IBM Rational Functional

Tester• HP QuickTest

http://www.junit.org/

http://testng.org/doc/index.html

http://testng.org/doc/index.html


1) En primer lugar se crea el scripting que define la navegación y las acciones

que se tienen que realizar contra la aplicación (apretar botón, introducir datos,

etc.), bien de forma manual, bien con el mecanismo de "grabación" ofrecido

por la herramienta.

2) En segundo lugar se configura un perfil operacional en el que se definen el

número de usuarios que se simularán (usuarios virtuales), en qué intervalo de

tiempo irá entrando cada uno de ellos (rampa de entrada) y los datos que se

utilizarán de entrada para cada usuario simulado.

3) Por último, al ejecutar las pruebas la herramienta genera carga real contra

el sistema con la navegación definida y el perfil operacional.

Una vez se han iniciado las pruebas, el componente de análisis de la herra-

mienta registra durante toda la prueba cuántos usuarios se están simulando,

qué acciones están realizando y los tiempos de respuesta obtenidos por cada

acción. Esta información, contrastada con los requisitos, nos da idea de si el

aplicativo está preparado para asumir la carga esperada o cuáles son las con-

diciones máximas que puede permitir.

Ejemplo de ejecución con JMeter


Durante las pruebas de rendimiento son muy útiles las herramientas de mo-

nitorización, que dan información del estado del sistema mientras se está uti-

lizando (servidores, redes, rendimiento, aplicaciones, etc.). Con estas herra-

mientas podemos identificar posibles cuellos de botella (sentencias SQL poco

óptimas, código poco eficiente, etc.), monitorizar el tráfico de red y obtener

información valiosa en tiempo real e histórico.

Herramientas de ejecución de pruebas de seguridad

Hay herramientas de propósito especial para detectar problemas de seguridad

en las aplicaciones. Estas herramientas detectan, entre otras, vulnerabilidad

del tipo SQLInjection y Cross Site Scripting. La mayoría se basan en dar cum-

plimiento a las buenas prácticas establecidas por el OWASP (open web applica-

tion security project).

Habitualmente, es en las pruebas de seguridad donde encontramos más falsos

positivos, es decir, fallos que realmente no son tales. En estos casos tendremos

que confirmarlo de forma manual.

Herramientas de ejecución de pruebas de accesibilidad

En el ámbito específico de aplicaciones web podemos encontrar herramientas

para analizar diferentes aspectos:

• Detectar enlaces rotos entre las páginas.

• Validar si la sintaxis HTML es correcta.

• Validar la accesibilidad de las páginas. Están orientadas a detectar el segui-

miento del cumplimiento de las normas establecidas por el W3C en ma-

teria de accesibilidad y reconocer qué nivel de cumplimiento tiene la web.

La herramienta TAW (test de accesibilidad web) desarrollada por la Fundación CTIC (Principado de Asturias) permite comprobarde forma automática si un aplicativo cumple las normas incluidas en el WCAG.

OWASP

El OWASP es un proyecto decódigo abierto para determi-nar y combatir las causas quehacen que el software sea inse-guro.

Herramientas dereferencia

Algunas herramientas de refe-rencia para la ejecución de laspruebas de seguridad son:• WebScarab• IBM AppScan• HP WebInspect


6.4. Herramientas para la ejecución de pruebas estáticas

6.4.1. Herramientas de revisión

Algunas herramientas de modelado permiten validar los modelos diseñados,

comprobando, por ejemplo, la consistencia en las relaciones entre las tablas

de una base de datos o la consistencia de un modelo en UML.

Las herramientas de gestión de requisitos también pueden contener informa-

ción muy valiosa que permiten, entre otros:

Microfocus Together

Un ejemplo típico de herra-mienta de revisión es Microfo-cus Together.

• Comprobar la consistencia entre los requisitos.

• Comprobar aspectos ambiguos en los requisitos (algunas palabras clave co-

mo "puede", "habría de"...), expresiones no permitidas, legibilidad o tiem-

pos verbales incorrectos.

• Identificar requisitos sin definir o "por definir más adelante".

• Comprobar la trazabilidad con las pruebas y su cobertura.

6.4.2. Herramientas de análisis estático de código

Visure IRQA

La herramienta Visure IRQAes capaz de detectar aspectosambiguos en los requisitos.

Las herramientas de análisis estático de código permiten entender la estructu-

ra del código y evaluar el seguimiento de estándares de codificación y buenas

prácticas de programación. Aportan, entre otras, las siguientes funcionalida-

des:

• Obtención de métricas de código (complejidad ciclomática, fan-in, fan-

out...).

• Seguimiento de normas de codificación.

• Análisis de la estructura y dependencias (ver qué relaciones existen entre

diferentes clases, componentes, etc.).

• Identificación de defectos.

Estas herramientas permiten generar informes detallados de los incumpli-

mientos y en qué puntos específicos del código se tienen que realizar las co-

rrecciones.

Herramientas paraanalizar código Java

Las herramientas más utiliza-das para analizar código Javason:• Checkstyle (gratuita)• Findbugs (gratuita)• PMD (gratuita)• Sonar (integra las anteriores

en un cuadro de mandos)• Parasoft JTest


Ejemplo de Sonar, un cuadro de mandos para el análisis de la calidad del código Java

6.5. Herramientas de soporte al desarrollo

En este grupo se incluyen todas las herramientas que pueden usar los desarro-

lladores para programar con más calidad, localizar defectos y realizar su co-

rrección.

6.5.1. Herramientas de soporte a la programación

En general, las diferentes herramientas de programación ofrecen utilidades

que reducen el tiempo necesario para desarrollar código (plantillas, generación

automática de código, etc.), así como también para evitar la introducción de

defectos y usar buenas prácticas de programación, como, por ejemplo:

• Asistir automáticamente al programador incorporando automáticamente

el corchete de final del bloque ("}") cuando el programador introduce el

corchete de inicio ("{").

• Eliminar los 'import' no utilizados.

• Autocompletar funciones con búsqueda asistida.

• Comprobar en tiempo real, a medida que se programa, si se están cum-

pliendo los estándares y buenas prácticas de programación. La mayoría de

las herramientas de análisis estático estudiadas anteriormente tienen una

versión específica integrada con el entorno de desarrollo.

FindBugs

FindBugs, por ejemplo, tie-ne un plugin para Eclipse quenos marca aquellos puntos denuestro código que incumplenlas buenas prácticas de progra-mación.


Ejemplo donde el programador ve al momento que lacomparación entre cadenas no es correcta (se marca elincumplimiento o mala práctica con un icono de defecto a laizquierda de la línea).

6.5.2. Herramientas de depuración

Al principio del desarrollo de una transacción de negocio o de un método

puede ser interesante usar una herramienta de depuración para verificar que el

código está haciendo lo que esperábamos mientras lo estábamos implemen-

tando, o para ayudarnos a explorar un código que se comporta de una forma

que no entendemos (qué valores tienen los datos, qué camino se toma...).

La mayoría de las herramientas de desarrollo ofrecen herramientas de depura-

ción. La ejecución de la depuración se realiza en los siguientes pasos:

1) El programador determina en qué puntos del código fuente el depurador

tendrá que detener su ejecución (puntos de interrupción).

2) El programador arranca desde la herramienta de desarrollo el aplicativo en

modo de depuración.

3) El programador entra en el aplicativo como si se tratara de un usuario real

y navega hasta que el depurador determina que se ha pasado por un punto

de interrupción.

4) El depurador interrumpe la ejecución y muestra de forma destacada dentro

del código fuente la línea en la que se ha detenido.

5) El programador evalúa en esta interrupción la memoria, los valores de las

variables del programa y determina la siguiente acción:

a) Ir paso a paso por el código fuente para analizar por qué puntos pasa la

ejecución.

b) Incorporar nuevos puntos de interrupción.

Puntos de interrupción

El punto de interrupción pue-de ser condicional (parar si he-mos llegado a la posición 10del bucle) o imperativo (pararsiempre si llegas a esta senten-cia).


c) Ejecutar determinadas partes del código, como el interior de una función

llamada por una función (de forma recursiva), o pasar a la siguiente interrup-

ción.

6.5.3. Herramientas de integración continua

Las herramientas de integración continua permiten realizar de forma desasis-

tida, y habitualmente diaria, la construcción del software, a partir del código

generado por diferentes desarrolladores y subido a la herramienta de control

de versiones, la ejecución de pruebas unitarias, la comprobación del cumpli-

miento de normas y estándares, el despliegue del aplicativo y la comprobación

funcional del mismo, todo ello de forma automática. Con la visión incremen-

tal de la herramienta en informes accesibles en web podemos prevenir defec-

tos durante todo el ciclo de vida.

6.5.4. Herramientas de gestión de la configuración

Diversas herramientas

Existen diferentes herramientasgratuitas de integración con-tinua, como Hudson, Conti-nuum o Cruise Control.

Las herramientas de gestión de la configuración no son en sí mismas herra-

mientas de pruebas, pero resultan vitales para una ejecución correcta de las

mismas. Cuando probamos una aplicación tenemos que saber cuál es la ver-

sión que probamos, ya que todos los activos de prueba dependerán de esta.

Todos los entregables generados durante las pruebas tienen cambios en el tiem-

po y están asociados a determinadas versiones del software a probar, por lo que

también tienen que ser almacenados y gestionados dentro de las herramientas

de gestión de la configuración.

Gestión de laconfiguración

En algunas ocasiones, una ma-la gestión de la configuraciónprovoca que se inviertan variassemanas en probar una versióndel software que no correspon-de a la versión que realmentese tenía que probar.


Resumen

Hemos iniciado el módulo con una detallada descripción de la misión que

tienen las pruebas, incluyendo su clasificación (niveles, características a pro-

bar...), sus fases y los entregables producidos en ellas (especificación del dise-

ño, casos de prueba y procedimientos, entre otros). Asimismo hemos descri-

to diferentes técnicas de diseño de pruebas, como, por ejemplo, la técnica de

clases de equivalencia.

Debido a que las pruebas no son suficientes por sí solas para evaluar la calidad,

hemos descrito el objetivo de las revisiones y el análisis estático. Las primeras

pueden ser clasificadas según su formalidad y tienen un proceso bien definido.

Para poder localizar defectos hemos recurrido al proceso de depuración y la

bitácora, un mecanismo habitual para registrar acontecimientos que nos per-

mitan reconocer las condiciones y la localización del código en el que se ha

producido un fallo o un defecto. Asimismo, el refactoring es una estrategia que

tiene que utilizarse continuamente para mantener la calidad de nuestro soft-

ware.

Como técnicas de prevención de defectos, podemos encontrar el análisis de la

causa raíz, los estándares de programación y la validación de los datos, en la

que se incluye el concepto de "diseño por contrato".

Para establecer una acción de recuperación en el caso de que se dé un fallo

hemos descrito el mecanismo de gestión de excepciones, considerando el tra-

tamiento que posibilita el lenguaje Java, como ejemplo.

Para finalizar el módulo hemos descrito diferentes herramientas que dan so-

porte a las diferentes técnicas analizadas, como las herramientas de gestión

de las pruebas, las herramientas para la ejecución de pruebas dinámicas o las

herramientas de análisis estático, entre otras.


Actividades

1. Identificad las clases de equivalencia para cada uno de los datos de entrada mostrados enla pantalla de ejemplo del sistema VCV del subapartado 1.6.1.

2. Suponed el siguiente diagrama que representa la realización de una reserva en el sistemaVCV y cómo se tiene que bloquear la plaza reservada (a fin de que no la pueda coger otrousuario) hasta su pago (o anularla):

Construir la tabla de estados correspondiente al diagrama superior para diseñar las pruebasnecesarias.

3. Supongamos en el sistema VCV el siguiente escenario:

• El sistema tiene que validar la reserva si la cuenta de la tarjeta corresponde a alguno delos pasajeros y el saldo de la tarjeta cubre el total de la reserva.

• El sistema tiene que enviar en caso de validación de reserva un correo electrónico deconfirmación.

• El sistema tiene que enviar confirmación por SMS si se ha marcado envío por SMS y elteléfono móvil indicado es correcto.

• El sistema tiene que descontar de la factura un 1% si el correo electrónico indicado co-rresponde a un usuario registrado en la web.

Definid la tabla de decisión correspondiente para las pruebas, eliminando aquellos casos queno sean posibles.

4. Proponed una lista de comprobación de la usabilidad de aplicativos web. A continuación,revisad qué es la accesibilidad y qué lista de comprobación define el W3C (World Wide Con-sortium). Describid de forma sucinta el concepto de prioridades y niveles de conformidad.

5. Definid qué es un oráculo de pruebas y dad algunos ejemplos.

6. Describid con un ejemplo aplicado al sistema VCV qué es SQL Injection. ¿Qué solucioneshay para prevenir este tipo de defectos?

7. Imaginad que un programador escribe el siguiente fragmento de código:


SqlConnection conn = null;try { conn = new SqlConnection(...); conn.open(); // código de ejecución de inserciones, consultas, etc. Statement smt = conn.createStatement(); ... ...// otro código conn.close()} catch (SQLException sqlExc) {}

¿Qué problema tiene este código? Proponed cuál tendría que ser el código correcto.

8. Escoged alguno de los proyectos publicados en http://nemo.sonarsource.org/ y analizadlos defectos más importantes encontrados. Buscad algún método en el que la complejidadciclomática sea superior a la máxima permitida y, caso de que sea posible, indicad cómo seha calculado.

Ejercicios de autoevaluación

1. Imaginad que, por una nueva ley de seguridad, todas las reservas realizadas en nuestrosistema VCV tendrán que ser notificadas a un sistema de la policía en el que nos tenemosque integrar. Suponed que este componente externo no estará desarrollado hasta dentro dedos meses, pero se quiere simular su interacción antes de que esté disponible. ¿Qué soluciónpropondríais?

2. En los siguientes casos de nuestro sistema VCV, identificad qué tipo de prueba o qué técnicautilizaríais:

a) Se quiere obtener feedback del mercado de una nueva aplicación para móviles que permitirála realización de las reservas.

b) Se quiere comprobar que esta nueva aplicación móvil funciona correctamente en diferen-tes plataformas de dispositivos móviles (Android, Symbian, Windows Phone y BlackberryOS).

c) Se quiere probar que nuestro sistema VCV envía un correo a la central de reservas si la fechade reserva es inferior a 3 días e incluye un aeropuerto de destino internacional, mientras quetiene que enviar un SMS en caso contrario.

d) Se quieren probar todas las condiciones del código de la función de facturación.

e) Nuestro sistema VCV, después de ser puesto en producción, cae por un número inesperadode accesos. Se quiere conocer cuál es el umbral máximo de usuarios que permite el sistema.

f) Nuestro sistema VCV genera un tique de reserva en formato PDF que tendría que poderser usado en diferentes versiones del programa Acrobat Reader.

g) Se quiere asegurar que los defectos previamente corregidos no vuelven a aparecer.

h) No se ha definido un plan de pruebas exhaustivo, pero se dispone de un probador conalta experiencia en encontrar defectos en sistemas de reservas.

3. ¿Qué tipo de técnica de detección de defectos propondríais para cada uno de los siguientescasos?

a) Se quiere analizar qué porcentaje de código duplicado tiene nuestro software del sistemaVCV.

b) Se quiere comprobar la evolución del proyecto y la existencia de desviaciones importantes.

c) Se quiere pedir a una entidad externa que nos certifique en el nivel 3 de CMMI.

d) Se quiere revisar un plan de pruebas basándose en una lista de comprobación.

e) Se quiere revisar si la arquitectura propuesta en nuestro sistema VCV es adecuada. Se pro-pone la participación de técnicos expertos.

http://nemo.sonarsource.org/


4. ¿Qué técnica de prevención, localización o corrección aplicaríais en los siguientes casos?

a) Por normas regulatorias tenemos que registrar todos los accesos que se realicen a nuestroaplicativo VCV.

b) Después de corregir un defecto en un fragmento de código, hemos encontrado diferentespuntos del código en el que aparece el mismo fragmento erróneo.

c) Nuestro sistema recibe eventos de fallo al comunicarse con el componente externo defacturación.

d) Durante el desarrollo se observa inexplicablemente que un dato entrado en una pantallapasa posteriormente a ser almacenado con otro valor. Queremos comprobar dónde se cambiael valor internamente.

e) En repetidas ocasiones se producen fallos en el entorno productivo motivados por valoresde negocio válidos, pero complejos. El desarrollador tiene un script de base de datos querealiza la corrección rápidamente, pero no se ha encontrado una solución permanente.

f) Nuestro sistema VCV ha incorporado un espacio en el que la gente puede publicar las guíasde sus viajes. El sistema no es capaz de recibir documentos adjuntos superiores a 10 Mb, perosigue permitiendo que el usuario suba documentos de cualquier tamaño.


Solucionario

Actividades

Solución�de�la�actividad�1

Una posible solución sería la que se puede ver en la tabla siguiente.

Campo Clases de equivalencia válidas Clases de equiva-lencia inválidas

Ida y vuelta / Vuelta Ida y vueltaVuelta (2 clases válidas)

Aeropuerto origen o destino Origen estatal y destino estatalOrigen estatal y destino interna-cionalOrigen internacional y destino es-tatalOrigen internacional y destino in-ternacional

Fecha de ida Fecha>Hoy <=Hoy

Fecha de vuelta >Fecha ida <=Fecha ida

Adultos 1-50 (no se permite que viajen ni-ños solos, si se permitiera, sería0-50)

<1>50 (2 clases inválidas)

Texto alfanumérico

Niños 0-5 <0>5

Bebés 0-2 <0>2

Categoría BusinessTurista (2 clases válidas)

Soy flexible en las fechas, Solovuelos directos,Incluir low cost

SíNo


La tabla de estados correspondiente es:

Estado actual Evento/con-dición

Acción Nuevo estado

Libre Vuelo seleccionado Bloquear Introduciendo datos

Introduciendo datos Aceptar datos - Pendiente de pago

Introduciendo datos Tiempo>15 min. Desbloquear y cerrar sesión Libre

Pendiente de pago Pago no realizado Enviar correo Libre

Pendiente de pago Pago realizado Enviar correo confirmación Cerrada


Algunos de los casos de prueba no son aplicables o reales. Si la cuenta titular no correspondea ningún pasajero, no hace falta que comprobemos nada más, ya que la reserva no se podrá


realizar, y, por tanto, no se enviará ninguna confirmación ni se aplicará ningún descuento.En caso de que sí corresponda a algún pasajero, pero la cuenta no tenga saldo, tampocotendrá sentido comprobar si el usuario está registrado o si ha marcado envío por SMS. Por lotanto, la tabla final de decisión y, consecuentemente, los diferentes casos de prueba (6) serán:

Condición 1 2 3 4 5 6

¿Cuenta titular de algún pasajero? S S S S S N

¿Cuenta con saldo? S S S S N -

¿Usuario registrado? S S N N - -

¿Marcada confirmación por SMS? S N S N - -

Acciones

Validar reserva y enviar correo S S S S

Enviar confirmación SMS S S

Descontar factura S S

Mensaje error S S


Una lista de comprobación para la usabilidad de páginas podría contener los siguientes cri-terios:

Grupo de criterios Criterio

Navegación • ¿Se muestra claramente la localización al usuario dentro del sitioweb?

• ¿Se identifica de forma clara cómo ir a la página principal?• ¿Las partes más importantes son accesibles desde la página prin-

cipal?• ¿Se facilita una función de búsqueda?

Funcionalidad • ¿Se puede acceder desde un nivel principiante y uno experto?• ¿Las funciones se identifican claramente?• ¿Solo se usan plugins (Flash, Applet...) cuando aportan valor?

Control al usuario • ¿El usuario puede cancelar cualquier operación?• ¿Están soportados los navegadores más habituales? (Firefox, Ex-

plorer...)• ¿El tamaño de las páginas es inferior a 50 K para permitir el

acceso a conexiones lentas?

Ayuda al usuario • ¿Se muestra una pantalla de confirmación para las operaciones?• ¿Se aporta en cada página la fecha de última actualización?• ¿Se aportan ayudas contextuales a los componentes?

Accesibilidad • Referirse a la guía WAI del W3C

Con el nombre WAI (web accessibility initiative) se describe un conjunto de guías y herra-mientas para la evaluación de la accesibilidad de páginas web. La guía WCAG (web content


accessibility guidelines) incluye una lista de comprobación para el desarrollo de páginas webaccesibles, donde cada comprobación tiene asignada una prioridad:

• Prioridad 1. Se tiene que cumplir obligatoriamente. Si no se cumple, algunos grupos en-contrarán imposible acceder al contenido web. Ejemplo: Asegurar que toda la informa-ción mostrada con color también es comprensible sin color.

• Prioridad 2. Se tendría que cumplir.• Prioridad 3. Puede cumplirla o no.

En función de estos puntos asignados a cada comprobación se puede establecer un nivel deconformidad de todo el aplicativo web: "A" si se han satisfecho todos los puntos de compro-bación con prioridad 1, "AA" si se han satisfecho todos los puntos de comprobación conprioridad 1 y 2, y "AAA" si se han satisfecho todos los puntos de comprobación con prioridad1, 2 y 3.


Un oráculo es cualquier programa, proceso o dato que proporciona información de cuál tieneque ser el resultado de un conjunto de pruebas. Es requerido en casos en los que no podemosdeterminar fácilmente cuáles son los resultados esperados de la prueba. Algunos ejemplosque nos pueden servir como oráculo son: oráculo heurístico con los resultados aproximadoso exactos de los resultados para un conjunto de entradas de prueba, un juicio humano (¿haceel programa lo que parece correcto para el usuario?), comparar los resultados de las pruebascon las mismas pruebas realizadas con versiones anteriores del aplicativo, o incluso compararlos resultados con una tabla, fórmula u otros elementos definidos como salidas válidas.


La inyección SQL es el proceso de insertar código SQL dentro de otro código SQL con elobjetivo de cambiar el funcionamiento normal de la sentencia SQL original. Supongamosque en nuestro sistema de reserva de vuelos del sistema VCV existe una opción llamada "Verreservas realizadas". Como resultado de apretar el enlace se realiza una petición al servidoren la que se incorpora como parámetro nuestro identificador de usuario.

http://viajar.uoc.edu/verReservas.do?idUsuario=12939

Esta petición llega al servidor que procesa la petición y lanza la siguiente sentencia SQL enla base de datos:

SELECT * FROM reservas WHERE id_usuario=12939

Como resultado el servidor genera una página de salida HTML al usuario en la que se muestrala información de las reservas realizadas.

Supongamos ahora, en cambio, un ataque malicioso no controlado por el sistema, en el quese nos envía la siguiente petición:

http://viajar.uoc.edu/verReservas.do?idUsuario=%20OR%20%22=

Esta petición llegaría a ser ejecutada con la siguiente sentencia SQL:

SELECT * FROM reservas WHERE id_usuario=" OR =";

¡Eso provocaría que se pudieran ver todas las reservas de todos los usuarios del sistema!

La solución para evitar este ataque es aplicar una validación a los datos, por ejemplo, limi-tando el tamaño del valor y prohibiendo el uso de caracteres como comillas simples ('), puntoy coma (;), etc.


Supongamos que se da una excepción en el código llamado entre la sentencia conn.open yconn.close(). Automáticamente el código continúa en el bloque catch, y nunca se reali-zará la sentencia conn.close(), con lo que la conexión se quedará abierta e inutilizada. Sipensamos que este código es ejecutado por cada petición que se haga en el sistema, el sistemase quedará rápidamente sin conexiones y la única solución será reiniciar el sistema cuandoya sea demasiado tarde y muchos usuarios hayan estado sin poder trabajar un buen rato.

La solución correcta sería:


SqlConnection conn = null;try { conn = new SqlConnection(...); conn.open(); // código de ejecución de inserciones, consultas, etc. // otro código conn.close()} catch (SQLException sqlExc) { // tratamiento de la excepción} finally { if(conn != null) { conn.close(); conn = null; }}


Respuesta libre

Ejercicios de autoevaluación

1. Una solución es desarrollar un stub que simule el componente externo, devolviendo siem-pre un resultado positivo. En el momento en que esté disponible el componente externopodremos volver a reactivar el código "real".

2.a) Pruebas beta

b) Pruebas de compatibilidad

c) Técnica de tablas de decisión

d) Técnica dinámica de caja blanca basada en condiciones

e) Pruebas de estrés

f) Pruebas de compatibilidad

g) Pruebas de regresión

h) Pruebas exploratorias

3.a) Análisis estático

b) Revisión de gestión

c) Auditoría

d) Inspección

e) Revisión técnica

4.a) Bitácora. Podríamos registrar desde el código cada acceso a una base de datos o un fi-chero.

b) Refactoring. Convendría establecer una función que incluyera el fragmento correcto y fuerallamado desde los puntos en los que previamente se duplicaba el código.

c) Gestión de excepciones.

d) Depuración (herramienta). Mediante la depuración con una herramienta podríamos irpaso a paso en la ejecución y analizar el valor de la variable en cada momento, hasta detectaren qué punto se cambia el valor recibido.

e) Análisis de causa raíz. Se tendría que analizar cuál es la causa real del fallo y estableceracciones correctivas específicas que eviten soluciones "temporales" (como el script) que nomitigan el problema real.

f) Validación de datos. Se tendría que validar que el documento adjunto no supere los 10 Mby mostrar un mensaje al usuario indicando esta restricción.


Glosario

alpha testing (pruebas alpha) f pl Tipo de pruebas para paquetes destinados al público,realizadas en la ubicación del equipo de desarrollo.

aserción f Predicado ubicado por un desarrollador en un punto del código donde consideraque se satisface el predicado.

beta testing (pruebas beta) f pl Tipo de pruebas para paquetes destinados al público,realizadas en instalaciones del usuario final.

big-bang m Estrategia de pruebas de integración no incremental.

bitácora f Registro de acontecimientos cronológicos de lo que hace un sistema o aplicativodurante su ejecución.

caso de prueba m Elemento de prueba con las condiciones de ejecución y el conjuntode datos de entrada de prueba.

código muerto m Fragmento o región de un código que no será nunca ejecutado porqueno se da ninguna condición para que se pueda llegar a él.

condición de prueba f Aspecto o característica de un componente o sistema que podráser verificado mediante una prueba.

depuración f Proceso de búsqueda, análisis y eliminación de las causas de un fallo. Otraacepción incluye la utilidad dada por las herramientas de desarrollo para analizar en tiempode ejecución el estado de las variables y trazar el camino seguido por el programa.

depreciar v tr Acción que deja un elemento en estado transitorio, pendiente de elimina-ción, pero que se mantiene durante un tiempo para evitar el impacto que provoca el cambioa los elementos que lo utilizan.

driver m Pieza de software que simula un módulo o componente todavía no finalizado quetiene que interactuar con un componente ya existente a probar.

extreme programming f Metodología de desarrollo ágil, basada en el uso de programaciónpor pares, revisiones de código continuas y pruebas unitarias en todo el código.

file transfer protocol m Protocolo de red para la transferencia de ficheros entre sistemasque estén conectados con TCP. sigla FTP

FTP m Ver file transfer protocol.

invariante f Condición que se cumple durante toda la ejecución de un fragmento o fun-ción de un código.

logging m Ver bitácora.

poscondición f Condición que se ha satisfacer después de un fragmento de código o fun-ción.

precondición f Condición que se ha satisfacer antes de que empiece un fragmento de uncódigo o función.

procedimiento de prueba m Documento descriptivo de los pasos a ejecutar por un con-junto de casos de prueba.

refactoring f Proceso realizado sobre el software a fin de que sea más fácil de entender ymodificar sin cambiar su comportamiento externo u observable.

simple network management protocol m Protocolo para facilitar la transferencia deinformación de administración sobre el funcionamiento de la red, de un servidor, etc. siglaSNMP

smoke test (prueba de humo) m Subconjunto de los casos de prueba totales que permitevalidar que el sistema cumple los mínimos requeridos para poder ser probado.

SNMP m Ver simple network management protocol.


stub m Pieza de software que permite simular un módulo o componente inferior que noexiste o todavía no está finalizado.

taxonomía f Clasificación de una especie, concepto o elemento.

TCP m Ver transmission control protocol.

transmission control protocol m Protocolo básico de Internet que garantiza la entregaentre dos sistemas porla red. Sigla TCP


Bibliografía

Black, R. (2008). Advanced Software Testing (vol. 1). Rocky Nook.

Burnstein, I. (2003). Practical Software Testing. Spring.

Butcher, P. (2009). Debug It!. The Pragmatic Programmers.

Copeland, L. (2004). A Practitioner's Guide to Software Test Design. Artech House

Fewster, M.; Graham, D. (2009). Software Testing Automation - Effective use of test executiontools. Addison Wesley.

Graham, D.; Van Veenendaal, E.; Evans, I.; Black, R. (2008). Foundations of SofwareTesting. Course Technology Cengage Learning.

Koomen, T.; Van der Aalst, L., y otros (2006). TMap Next for result-driven testing. UTNPublishers.

McConell, S. (2004). Code complete. Microsoft Press.

Myers, G. J. (2004). The Art of Sofware Testing. John Wiley and Sons.

Wiegers, K. E. (2003). Software requirements. Microsoft Press.

software: técnicas calidad del de prevención, detección y …uoc.gitlab.io/2015/desarrollo...

Documents