pruebas de software y junit - daniel bolanos alonso

Daniel Bolaos Alonso Almudena Sierra Alonso Miren Idoia Alarcn Rodrguez

Pruebas de Software y JUnit Un anlisis en profundidad y ejemplos prcticos

Incluye CD

00-Portadillas 29/10/07 08:31 Pgina 2

Pruebas de Software y JUnitUn anlisis en profundidad y ejemplos prcticos


Pruebas de Software y JUnitUn anlisis en profundidad y ejemplos prcticos

Daniel Bolaos AlonsoDepartamento de Ingeniera Informtica

Universidad Autnoma de Madrid

Almudena Sierra AlonsoDepartamento de Ciencias de la Computacin

Universidad Rey Juan Carlos

Miren Idoia Alarcn RodrguezDepartamento de Ingeniera Informtica

Universidad Autnoma de Madrid

Madrid Mxico Santa Fe de Bogot Buenos Aires Caracas Lima Montevideo San Juan San Jos Santiago So Paulo White Plains


Queda prohibida, salvo excepcin prevista en la Ley, cualquier forma de reproduccin, distribucin, comunicacin pblica y transformacin de esta obra sin contar con autorizacin de los titulares de propiedad intelectual. La infraccin de los derechos mencionados puede ser constitutiva de delito contra la propiedad intelectual (arts. 270 y sgts. Cdigo Penal).

DERECHOS RESERVADOS 2007 por PEARSON EDUCACIN, S. A.Ribera del Loira, 2828042 Madrid (Espaa)

PRUEBAS DE SOFTWARE Y JUNITUN ANLISIS EN PROFUNDIDAD Y EJEMPLOS PRCTICOSBolaos, D.; Sierra, A.; Alarcn, M. I.

ISBN: 978-84-8322-354-3

Depsito Legal: M. PEARSON PRENTICE HALL es un sello editorial autorizado de PEARSON EDUCACIN, S.A.

Equipo editorial:Editor: Miguel Martn-RomoTcnico editorial: Marta Caicoya

Equipo de produccin:Director: Jos A. ClaresTcnico: Jos A. Hernn

Diseo de cubierta: Equipo de diseo de PEARSON EDUCACIN, S. A.Composicin: JOSUR TRATAMIENTOS DE TEXTOS, S.L.Impreso por:

IMPRESO EN ESPAA - PRINTED IN SPAIN

Este libro ha sido impreso con papel y tintas ecolgico

PRUEBAS DE SOFTWARE Y JUNITUN ANLISIS EN PROFUNDIDAD Y EJEMPLOS PRCTICOSBolaos Alonso, D.; Sierra Alonso, A.; Alarcn Rodrguez, M. I.

PEARSON EDUCACIN, S.A., Madrid, 2007ISBN: 978-84-8322-354-3

Materia: Informtica, 004

Formato: 195 250 mm Pginas: 368

Datos de catalogacin bibliogrfica


A Jess, Genoveva y Berta.Daniel Bolaos Alonso

A Jorge y AlejandroAlmudena Sierra Alonso

A ngel y PaulaMiren Idoia Alarcn


Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Captulo 1. Fundamentos de las pruebas de software . . . . . . . . . . . . 11.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Principios bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1. Verificacin y validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Tareas bsicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Inspecciones de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5. Pruebas basadas en la ejecucin del cdigo: tcnicas . . . . . . . . . . . . . . . . 5

1.5.1. Pruebas de caja blanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.1.1. Pruebas de interfaces entre mdulos o clases . . . . . . . . 61.5.1.2. Prueba de estructuras de datos locales . . . . . . . . . . . . . 61.5.1.3. Prueba del camino bsico . . . . . . . . . . . . . . . . . . . . . . . 61.5.1.4. Pruebas de condiciones lmite . . . . . . . . . . . . . . . . . . . 81.5.1.5. Pruebas de condicin . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5.2. Pruebas de caja negra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5.2.1. Particin de equivalencia . . . . . . . . . . . . . . . . . . . . . . . 131.5.2.2. Anlisis de valores lmite . . . . . . . . . . . . . . . . . . . . . . . 13

1.6. Diseo de casos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.7. Estrategia de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.7.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.7.2. Pruebas de integracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.7.2.1. Pruebas de integracin ascendentes . . . . . . . . . . . . . . . 211.7.2.2. Pruebas de integracin descendentes . . . . . . . . . . . . . . 211.7.2.3. Pruebas de integracin sandwich . . . . . . . . . . . . . . . . . 221.7.2.4. Eleccin del mdulo/clase crtico/a . . . . . . . . . . . . . . . 221.7.2.5. Acoplamiento y cohesin . . . . . . . . . . . . . . . . . . . . . . . 22

ndice01-Indice 26/10/07 09:46 Pgina vii

viii CONTENIDO

1.7.3. Pruebas de validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.7.3.1. Pruebas alfa y beta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.7.4. Pruebas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.7.5. Pruebas de aceptacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.8. Pruebas de sistemas orientados a objetos . . . . . . . . . . . . . . . . . . . . . . . . . 251.8.1. Pruebas de clases de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.8.2. Pruebas de integracin de objetos . . . . . . . . . . . . . . . . . . . . . . . . 26

1.8.2.1. Pruebas de interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.3. Pruebas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.9. Depuracin de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.10. Otras pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.10.1. Pruebas de regresin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.10.2. Pruebas de estrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.10.3. Pruebas de interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.11. Criterios para dar por finalizadas las pruebas . . . . . . . . . . . . . . . . . . . . . . 281.12. Equipo de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.13. Errores ms comunes que se cometen en la fase de pruebas . . . . . . . . . . . 301.14. Documentacin de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.15. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Captulo 2. Pruebas unitarias: JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.1.1. Aportaciones de JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.1.2. Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2. Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.1. Comprobacin de la correcta instalacin de JUnit . . . . . . . . . . . . 39

2.3. Primera toma de contacto con JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4. Creacin de una clase de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.1. Creacin de una clase de pruebas con JUnit 3.8.1 . . . . . . . . . . . . 432.4.2. Creacin de una clase de pruebas con JUnit 4.x . . . . . . . . . . . . . 47

2.5. Conceptos bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.5.1. Prueba de constructores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.5.1.1. Procedimiento de prueba de un constructor . . . . . . . . . 512.5.2. Prueba de mtodos get y set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.5.2.1. Prueba de mtodos get y set mediante la tcnica de cajablanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.5.2.2. Prueba de mtodos get y set mediante la tcnica de cajanegra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.5.3. Prueba de mtodos convencionales . . . . . . . . . . . . . . . . . . . . . . . 572.5.3.1. Casos particulares: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

01-Indice 26/10/07 09:46 Pgina viii

2.6. Organizacin de las clases de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.7. Ejecucin de los casos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.7.1. Mecanismos de ejecucin de los casos de prueba . . . . . . . . . . . . 622.7.1.1. Ejecucin en modo texto . . . . . . . . . . . . . . . . . . . . . . . 632.7.1.2. Ejecucin en modo grfico . . . . . . . . . . . . . . . . . . . . . . 64

2.7.2. Interpretacin de los resultados obtenidos . . . . . . . . . . . . . . . . . . 672.7.2.1. Concepto de error en JUnit . . . . . . . . . . . . . . . . . . . . . . 672.7.2.2. Concepto de fallo en JUnit . . . . . . . . . . . . . . . . . . . . . . 68

2.8. Conceptos avanzados en la prueba de clases Java . . . . . . . . . . . . . . . . . . . 692.8.1. Prueba de excepciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.8.1.1. Excepciones esperadas . . . . . . . . . . . . . . . . . . . . . . . . . 702.8.1.2. Excepciones no esperadas . . . . . . . . . . . . . . . . . . . . . . 76

2.8.2. Prueba de mtodos que no pertenecen a la interfaz pblica . . . . . 762.8.2.1. Prueba de forma indirecta . . . . . . . . . . . . . . . . . . . . . . 772.8.2.2. Modificar el atributo de privacidad de modo que los

mtodos sean accesibles desde el paquete . . . . . . . . . . 782.8.2.3. Utilizar clases anidadas . . . . . . . . . . . . . . . . . . . . . . . . 792.8.2.4. Utilizar la API de Reflection de Java . . . . . . . . . . . . . . 79

2.9. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Captulo 3. Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.2. Instalacin y configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.3. Conceptos bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.3.1. Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.3.1.1. Estructuras Path-Like . . . . . . . . . . . . . . . . . . . . . . . . . . 873.3.1.2. Grupos de ficheros y directorios . . . . . . . . . . . . . . . . . . 88

3.3.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.3.3. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.3.3.1. Tareas sobre ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . 913.3.3.2. Tareas de acceso al sistema de ficheros . . . . . . . . . . . . 923.3.3.3. Tareas de compilacin . . . . . . . . . . . . . . . . . . . . . . . . . 933.3.3.4. Tareas de documentacin . . . . . . . . . . . . . . . . . . . . . . . 933.3.3.5. Tareas de ejecucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943.3.3.6. Tareas para la definicin de propiedades . . . . . . . . . . . 953.3.3.7. Tareas relacionadas con las pruebas . . . . . . . . . . . . . . . 953.3.3.8. Tareas definidas por el usuario . . . . . . . . . . . . . . . . . . . 963.3.3.9. Otras tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.4. Creacin de un proyecto bsico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993.5. Ejecucin de los casos de prueba mediante Ant . . . . . . . . . . . . . . . . . . . . 1013.6. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

CONTENIDO ix

01-Indice 26/10/07 09:46 Pgina ix

Captulo 4. Gestin de la configuracin del Software . . . . . . . . . . . . . 1094.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094.2. Principios bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114.4. Lneas base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4.4.1. Elementos de configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.4.2. Lneas base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4.5. Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144.6. Control de cambios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.6.1. Motivos del cambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174.7. Herramientas de GCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184.8. Documentacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.8.1. Plan de GCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204.8.2. Formulario de Peticin de Cambios . . . . . . . . . . . . . . . . . . . . . . . 1204.8.3. Informes de Cambios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214.8.4. Otros documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

4.9. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Captulo 5. Herramientas de control de versiones: Subversion (SVN) . 1255.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.2. Por qu utilizar Subversion? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265.3. Descripcin general de Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265.4. Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.4.1. Servidor basado en svnserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285.4.1.1. Autenticacin con svnserve . . . . . . . . . . . . . . . . . . . . . 129

5.4.2. Servidor basado en Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.5. Creacin de repositorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.5.1. La estructura del repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.5.2. Acceso al repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.5.3. Mantenimiento del repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.6. Autenticacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.7. Autorizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.7.1. Control de acceso general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.7.2. Control de acceso basado en directorios . . . . . . . . . . . . . . . . . . . 137

5.7.2.1. Definicin del fichero de control de acceso . . . . . . . . . 1395.8. Puesta en marcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415.9. Trabajando con Subversion: TortoiseSVN . . . . . . . . . . . . . . . . . . . . . . . . 141

5.9.1. Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425.9.2. Conexin con el repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425.9.3. Ciclo de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

x CONTENIDO

01-Indice 26/10/07 09:46 Pgina x

5.9.4. Operaciones bsicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435.9.4.1. Importar datos al repositorio: Importar . . . . . . . . . . 1435.9.4.2. Obtener una copia de trabajo: SVN Obtener . . . . . . 1455.9.4.3. Enviar los cambios al repositorio: SVN Confirmar . 1465.9.4.4. Actualizar una copia de trabajo: SVN Actualizar . . . . 1495.9.4.5. Resolver conflictos: Editar conflictos y Resuelto . . . 1505.9.4.6. Registro de revisiones: Mostrar registro . . . . . . . . . . . . 1515.9.4.7. Otras operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.10. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Captulo 6. Generacin de informes sobre las pruebas . . . . . . . . . . . 1556.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.2. Informes con los resultados de ejecucin de las pruebas . . . . . . . . . . . . . 156

6.2.1. Utilizacin de la tarea JUnitReport de Ant para generar informescon los resultados de ejecucin de las pruebas . . . . . . . . . . . . . . . 156

6.2.2. Otras libreras de inters: JUnit PDF Report . . . . . . . . . . . . . . . . 1606.3. Informes sobre alcance de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

6.3.1. Utilizacin de la herramienta Cobertura para generar informesde cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636.3.1.1. Indicar a Ant la localizacin de las nuevas tareas . . . . 1646.3.1.2. Instrumentalizacin de las clases que van a ser pro-

badas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656.3.1.3. Ejecucin de las pruebas sobre las clases intrumentali-

zadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656.3.1.4. Generacin de los informes de cobertura . . . . . . . . . . . 1676.3.1.5. Establecimiento y verificacin de umbrales de cober-

tura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696.3.2. Interpretacin de los informes de cobertura . . . . . . . . . . . . . . . . . 172

6.3.2.1. Estimacin de recursos . . . . . . . . . . . . . . . . . . . . . . . . . 1746.3.2.2. Aseguramiento de la calidad de componentes software . 174

6.4. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Captulo 7. Pruebas unitarias en aislamiento mediante Mock Objects:JMock y EasyMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757.2. Diferencias entre Mock Objects y Stubs . . . . . . . . . . . . . . . . . . . . . . . . . . 1787.3. Filosofa de funcionamiento de los Mock Objects . . . . . . . . . . . . . . . . . . 1797.4. Procedimiento general de utilizacin de Mock Objects . . . . . . . . . . . . . . 1797.5. Herramientas para la puesta en prctica de la tcnica de Mock Objects:

EasyMock y JMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1817.5.1. EasyMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

7.5.1.1. Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827.5.1.2. Ejemplo de utilizacin de EasyMock . . . . . . . . . . . . . . 183

CONTENIDO xi

01-Indice 26/10/07 09:46 Pgina xi

xii CONTENIDO

7.5.2. JMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917.5.2.1. Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917.5.2.2. Ejemplo de utilizacin de JMock . . . . . . . . . . . . . . . . . 192

7.6. Comparativa entre EasyMock y JMock . . . . . . . . . . . . . . . . . . . . . . . . . . . 1967.7. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Captulo 8. Mejora de la mantenibilidad mediante JTestCase . . . . . . 1978.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1978.2. Conceptos bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

8.2.1. Creacin del documento XML con los casos de prueba . . . . . . . 2008.2.2. Acceso desde los mtodos de prueba a los casos de prueba defi-

nidos en los documentos XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 2048.2.3. Tratamiento de casos especiales . . . . . . . . . . . . . . . . . . . . . . . . . . 207

8.3. Definicin de parmetros complejos con JICE . . . . . . . . . . . . . . . . . . . . . 2118.4. JTestCase como herramienta de documentacin de los casos de prueba . 2188.5. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Captulo 9. Prueba de aplicaciones que acceden a bases de datos:DBUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.2. Tcnicas de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

9.2.1. Utilizacin de Mock Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2219.2.2. Utilizacin de una base de datos real . . . . . . . . . . . . . . . . . . . . . . 2229.2.3. Procedimiento y recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . 223

9.3. Prueba del cdigo perteneciente a la interfaz de acceso a la base de datos:DBUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2259.3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2259.3.2. Creacin de una clase de pruebas con DBUnit . . . . . . . . . . . . . . 226

9.3.2.1. Definicin de la clase de prueba . . . . . . . . . . . . . . . . . . 2269.3.2.2. Definicin de los mtodos de prueba . . . . . . . . . . . . . . 229

9.3.3. Definicin de los casos de prueba . . . . . . . . . . . . . . . . . . . . . . . . 2449.3.4. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

9.4. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Captulo 10. Pruebas de documentos XML: XMLUnit . . . . . . . . . . . . . 24710.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24710.2. Configuracin de XMLUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24810.3. Entradas para los mtodos de XMLUnit . . . . . . . . . . . . . . . . . . . . . . . . . 25010.4. Comparacin de documentos XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

10.4.1. Qu mtodos de asercin utilizar para comparar cdigo XML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

10.5. Cmo salvar diferencias superficiales . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

01-Indice 26/10/07 09:46 Pgina xii

10.5.1. Ignorar los espacios en blanco . . . . . . . . . . . . . . . . . . . . . . . . . 25310.5.2. Ignorar los comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25410.5.3. La interfaz DifferenceListener . . . . . . . . 254

10.6. Prueba de transformaciones XSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25510.7. Validacin de documentos XML durante el proceso de pruebas . . . . . . 256

10.7.1. Validacin frente a un DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 25710.7.2. Validacin frente a un esquema XML . . . . . . . . . . . . . . . . . . . 258

10.8. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Captulo 11. Prueba de aplicaciones Web . . . . . . . . . . . . . . . . . . . . . . . 25911.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25911.2. Herramientas para la automatizacin de la prueba . . . . . . . . . . . . . . . . . 260

11.2.1. HttpUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26211.2.2. HtmlUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26211.2.3. JWebUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

11.3. Prueba de un sitio Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26311.3.1. Pruebas de navegacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

11.3.1.1. Procedimiento general de prueba . . . . . . . . . . . . . . 26411.3.1.2. Utilizacin de JWebUnit y JtestCase para realizar

las pruebas de navegacin . . . . . . . . . . . . . . . . . . . . 26511.3.2. Prueba de enlaces rotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27311.3.3. Pruebas de estructura y contenido . . . . . . . . . . . . . . . . . . . . . . 274

11.3.3.1. Prueba de pginas Web dinmicas . . . . . . . . . . . . . 27511.3.3.2. Prueba de pginas HTML estticas . . . . . . . . . . . . 28111.3.3.3. Prueba de documentos XML generados dinmica-

mente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28311.4. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Captulo 12. Pruebas de validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29112.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29112.2. JFunc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

12.2.1. Procedimiento de utilizacion de JFunc . . . . . . . . . . . . . . . . . . . 29312.2.2. Ejecucin de las clases de prueba mediante JFunc . . . . . . . . . 29512.2.3. Mensajes detallados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

12.3. JUnitPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29712.3.1. Instalacin y configuracin de JUnitPerf . . . . . . . . . . . . . . . . . 29712.3.2. Creando pruebas con JUnitPerf . . . . . . . . . . . . . . . . . . . . . . . . 298

12.3.2.1. Pruebas de tiempo de respuesta: TimedTest . . . . 29812.3.2.2. Pruebas de carga: LoadTest . . . . . . . . . . . . . . . . . 30012.3.2.3. Pruebas combinadas de tiempo y carga . . . . . . . . . 30312.3.2.4. Ejecucin de las pruebas de rendimiento . . . . . . . . 306

12.4. JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

CONTENIDO xiii

01-Indice 26/10/07 09:46 Pgina xiii

12.4.1. Instalacin y configuracin de JMeter . . . . . . . . . . . . . . . . . . . 30712.4.2. Elementos de un plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . 309

12.4.2.1. ThreadGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30912.4.2.2. Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31012.4.2.3. Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31212.4.2.4. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31212.4.2.5. Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31212.4.2.6. Configuration Elements . . . . . . . . . . . . . . . . . . . . . 31212.4.2.7. Pre-Processor Elements . . . . . . . . . . . . . . . . . . . . . 31312.4.2.8. Post-Processor Elements . . . . . . . . . . . . . . . . . . . . . 31312.4.2.9. Reglas de alcance . . . . . . . . . . . . . . . . . . . . . . . . . . 31312.4.2.10. Orden de ejecucin . . . . . . . . . . . . . . . . . . . . . . . . . 31412.4.2.11. WorkBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

12.4.3. Creando pruebas con JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . 31612.4.3.1. Una prueba simple . . . . . . . . . . . . . . . . . . . . . . . . . 31612.4.3.2. Uso de parmetros en las peticiones . . . . . . . . . . . . 31812.4.3.3. Una prueba con varias peticiones . . . . . . . . . . . . . . 320

12.5. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Apndice A. Variables de entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323A.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323A.2 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Apndice B. Sistema a probar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327B.1 Descripcin general del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328B.2 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329B.3 Configuracin del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330B.4 Caractersticas del sistema y su relevancia en las pruebas de software . . . 331B.5 Arquitectura interna del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332B.6 Documento de especificacin de requisitos software . . . . . . . . . . . . . . . . 334

Apndice C. Estndares de nomenclatura y normas de estilo enJava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337C.1 Conceptos de clase y objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337C.2 Normas de estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Apndice D. Novedades en Java 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 341D.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341D.2 Anotaciones en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341D.3 Import esttico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

xiv CONTENIDO

01-Indice 26/10/07 09:46 Pgina xiv

A lo largo de los ltimos aos, debido al rpido desarrollo de la tecnologa, la complejidadde los sistemas software desarrollados se ha incrementado de una forma muy notable. Por estemotivo, la realizacin de un correcto proceso de pruebas, que permita culminar el proceso de de-sarrollo de un producto satisfaciendo enteramente las necesidades del cliente, cada da tiene ma-yor importancia.

Dentro de la fase de desarrollo de cualquier sistema software siempre se producen erroresque, independientemente de la fase (anlisis, diseo o codificacin) en que se introduzcan, en l-tima instancia siempre quedan plasmados sobre el cdigo de la aplicacin. Por tanto, es precisorevisar ese cdigo con el objetivo de detectar y eliminar dichos errores. Todos aquellos erroresque no se identifiquen antes de la entrega del producto aparecern durante su uso, con el con-siguiente perjuicio para el usuario y para el desarrollador. Por un lado el usuario se sentir in-satisfecho y frustrado, mientras que por el otro lado, el equipo de desarrollo tendr que volveratrs y buscar donde se ha producido el fallo para posteriormente corregirlo.

Tradicionalmente, la fase de pruebas del cdigo de un proyecto software tena lugar despusde la fase de codificacin y antes de la distribucin del producto al usuario. El fin era encontrarlos errores acumulados en las fases anteriores de anlisis y diseo y que han quedado plasmadosen el cdigo fuente, adems de los errores propios introducidos durante la codificacin. Sin em-bargo, se ha demostrado en numerosos casos prcticos, que realizar un proceso de pruebas enparalelo a toda la fase de desarrollo en lugar de nicamente al final, permite detectar los erroresde una forma ms temprana y solucionarlos a menor coste. A este respecto cabe destacar la apa-ricin de una metodologa de desarrollo software llamada Test Driven Development (desarrolloguiado por las pruebas) en la que las pruebas pasan a ser el centro del proceso de desarrollo, enel que el resto de tareas giran a su alrededor. Esta visin puede en un principio parecer un tantoradical, sin embargo, si el objetivo de cualquier proyecto software es producir un softwareque satisfaga las expectativas del cliente y esto solo se puede alcanzar mediante un adecuadoproceso de pruebas Por qu no centrar la fase de desarrollo en este proceso? Con este enfoque,las pruebas se definen a la vez que se va definiendo el producto y se automatizan de modo quepueden repetirse tantas veces como sea necesario: durante la puesta a punto del producto o du-rante las sucesivas acciones de mantenimiento que seguramente sufrir la aplicacin.

Un producto software se puede considerar un producto de calidad si cumple con todos los re-quisitos de usuario, software y requisitos implcitos. Tales como que el sistema se comporte de

Prefacio02-Prefacio 26/10/07 09:52 Pgina xvii

la forma esperada, que la interaccin con otros sistemas o elementos externos sea la adecuada,que sea robusto, que cumpla ciertos parmetros de rendimiento, etc. Justamente, verificar que elproducto desarrollado cumple todos estos requisitos, es la finalidad de las pruebas. Sin ningunaduda, la fase de pruebas incide de forma directa en la calidad, seguridad, eficiencia, correcciny completitud del producto software desarrollado.

Actualmente un gran porcentaje del esfuerzo, y por tanto del coste, que una empresa realizadurante el ciclo de vida de un proyecto software recae sobre la fase de mantenimiento. Duranteesta fase, el software evoluciona incorporando nuevas funcionalidades para dar respuesta anuevos requisitos del usuario, y corrigiendo errores que van apareciendo durante su uso. Por estemotivo, realizar una correcta fase de pruebas que permita producir un sistema fcilmente man-tenible y, por tanto, permita minimizar este esfuerzo, es de una gran importancia. Cuando se mo-difica un producto durante su mantenimiento, hay que someterlo a las pruebas de regresin paragarantizar que los cambios introducidos no traigan consigo ningn defecto. Si estas pruebas yaestn definidas y automatizadas, los recursos requeridos para las pruebas durante el manteni-miento se reducen considerablemente.

Una buena estrategia de pruebas incluye pruebas unitarias, de integracin, de sistema, fun-cionales o de validacin y de aceptacin. A lo largo de este texto se vern todas ellas. Inicial-mente, se ofrece una visin general de la fase de pruebas definiendo y explicando los conceptosms relevantes de dicha fase, sus actividades, el diseo de casos de pruebas, principios, estra-tegia, tcnicas, roles, productos generados, etc. Asimismo se describe el proceso de escritura delPlan de Pruebas, documento indispensable al inicio de toda fase de pruebas. Una vez realizadaesta introduccin, el lector se encuentra en disposicin de afrontar el resto de los captulos conuna base slida.

Estos captulos se centran en describir todo tipo de tcnicas de prueba sobre software Javamediante la utilizacin de herramientas pertenecientes a la familia JUnit. Estas tcnicas com-prenden: realizar pruebas unitarias, pruebas en aislamiento, pruebas de aplicaciones que accedena bases de datos, pruebas de aplicaciones WEB, pruebas de documentos estticos, pruebas derendimiento, etc. A la hora de describir estas tcnicas se ha seleccionado un conjunto de herra-mientas, todas ellas disponibles bajo licencias de software libre, que permiten ponerlas enprctica de una forma efectiva y cmoda para el desarrollador. Sin embargo, a pesar de que elprocedimiento de utilizacin de estas herramientas ocupa una buena parte de este libro, se ha tra-tado en la medida de lo posible de aislar las tcnicas de prueba en s mismas, de las herramien-tas que las llevan a la prctica. En el mundo del desarrollo software las herramientas de pruebacambian constantemente, sin embargo, la tcnica de prueba en la que se basan raras veces lohace. Por este motivo, el objetivo de este libro ha sido realizar una coleccin atemporal de tc-nicas y procedimientos de prueba que conserve su valor y utilidad independientemente de las he-rramientas utilizadas

A lo largo de este libro se han descrito en profundidad ms de 10 herramientas de pruebapertenecientes a la familia JUnit. Todas ellas permiten automatizar diferentes aspectos de laprueba de cdigo Java: JUnit para las pruebas unitarias, JUnitReport para generar informes so-bre los resultados de las pruebas, facilitando as su anlisis y almacenamiento, JMock y Easy-Mock para realizar pruebas de aislamiento de clases, JTestCase para separar el cdigo asocia-do a los casos de prueba de los datos usados para ejecutarlos, DBUnit para probar cdigo queaccede a bases de datos, HTTPUnit, HTMLUnit y JWEBUnit para probar aplicaciones Web,XMLUnit para comprobar la correcta generacin de cdigo XML y JFunc, JUnitPerf y JMeterpara las pruebas de validacin.

xvi PREFACIO

02-Prefacio 26/10/07 09:52 Pgina xviii

Este texto tambin incluye otras dos herramientas que proporcionan un importante apoyodurante la fase de pruebas: Ant y Subversin (SVN). La primera de ellas es una herramientabien conocida en el mundo de desarrollo Java y que presenta una serie de caractersticas que lahacen especialmente adecuada para la compilacin y creacin de cdigo Java en cualquier pla-taforma de desarrollo. Sin embargo este libro no pretende ser un manual de Ant sino introdu-cir los mecanismos que esta tecnologa proporciona para la realizacin de pruebas con JUnit.Por otro lado SVN, es una herramienta de control de versiones muy poderosa y actualmenteutilizada en infinidad de proyectos software. Junto con su front-end grfico conocido como Tor-toiseSVN, permite almacenar y recuperar versiones de cdigo fuente (en este caso cdigo depruebas y cdigo de produccin) as como de otros elementos software como archivos de datos,configuracin, etc.

Asimismo, cabe destacar que todos los captulos de este libro se apoyan en un nico casoprctico: una aplicacin Java (entregada en forma de CD junto con este libro y descrita en elApndice B del mismo) que proporciona informacin sobre el estado del trfico de carreteras.Esta aplicacin ha sido desarrollada exclusivamente con el objetivo de proporcionar un marcocomn sobre el que demostrar la utilizacin de las diferentes tcnicas de prueba tratadas a lo lar-go de este libro. De este modo la lectura del texto es didctica y comprensible, asistiendo en todomomento al lector y al desarrollador mediante la explicacin por medio de ejemplos analizadoshasta el ms mnimo detalle. Se ha cuidado la eleccin de los ejemplos para que resulten amenose ilustrativos, a la vez que se ha tratado de no pasar por alto aquellos aspectos en la aplicacin dedeterminadas tcnicas que resultan ms arduos.

Este libro viene a cubrir la escasez de literatura especializada en pruebas de software, reali-zando un anlisis comprometido y en profundidad sobre la materia con el objetivo de propor-cionar una visin global de este singular proceso, tan complejo como necesario.

Finalmente es importante destacar que este texto no ha sido escrito, en absoluto, en exclusivapara la enseanza universitaria. La intencin es que sirva de apoyo para todos aquellos desa-rrolladores del mundo Java que desean incorporar a su filosofa de trabajo una completa meto-dologa de pruebas de software con la que probar su cdigo de forma ms efectiva y alcanzar assus propsitos y objetivos, garantizando siempre la mxima calidad.

PREFACIO xvii

02-Prefacio 26/10/07 09:52 Pgina xix

02-Prefacio 26/10/07 09:52 Pgina xx

S U M A R I O

1.1. IntroduccinLas pruebas de software se definen como el proceso que ayuda a identificar la correccin,completitud, seguridad y calidad del software desarrollado. De forma genrica, por software seentiende el conjunto de datos, documentacin, programas, procedimientos y reglas que com-ponen un sistema informtico. Este libro, y consecuentemente este captulo, se centra en laspruebas de programas, es decir, de cdigo.

Este captulo cubre, entre otras cosas, los conceptos, principios y tareas bsicos de la fasede pruebas de un ciclo de vida de un proyecto informtico, el diseo de casos de prueba uti-lizando tcnicas que lleven a obtener un conjunto de casos con alta probabilidad de encontrar

Captulo 1Fundamentos de las pruebas de software

1.1. Introduccin1.2. Principios bsicos1.3. Tareas bsicas1.4. Inspecciones de cdigo1.5. Pruebas basadas en la ejecucin del

cdigo: tcnicas1.6. Diseo de casos de prueba1.7. Estrategia de pruebas1.8. Pruebas de sistemas orientados a objetos

1.9. Depuracin de errores

1.10. Otras pruebas

1.11. Criterios para dar por finalizadas laspruebas

1.12. Equipo de pruebas

1.13. Errores ms comunes que se cometen enla fase de pruebas

1.14. Documentacin de pruebas

1.15. Bibliografa

CAP-01 25/10/07 11:00 Pgina 1

errores en el cdigo, fin principal de las pruebas, y la estrategia de pruebas ms adecuada ycomnmente aceptada para probar de forma completa y consistente un sistema software par-tiendo tanto de un diseo estructurado como de un diseo orientado a objetos. Finalmente, seexplican algunos conceptos adicionales, tales como la depuracin de errores, los criterios paradar por finalizada la etapa de pruebas y los errores que se cometen ms habitualmente en estafase. Por ltimo se menciona la documentacin que se genera durante el proceso de pruebassoftware.

Se pretende, por tanto, proporcionar al lector una visin genrica de la fase de pruebas soft-ware. Con este captulo queda enmarcado el resto del libro, que se centra principalmente en laverificacin del cdigo y ms particularmente utilizando JUnit.

1.2. Principios bsicosComo definicin bsica del contenido de este libro, hay que mencionar, en primer lugar, queprueba es el proceso de ejecutar un conjunto de elementos software con el fin de encontrar erro-res. Por tanto, probar no es demostrar que no hay errores en el programa ni nicamente mostrarque el programa funciona correctamente, ambas son definiciones incorrectas y, sin embargo, co-mnmente utilizadas.

Otra definicin esencial es la de caso de prueba, trmino que se utilizar ampliamente a lolargo de todo este texto. Se define caso de prueba software como un conjunto de condiciones,datos o variables bajo las cuales el desarrollador determinar si el o los correspondientes re-quisitos de un sistema software se cumplen de forma parcial, de forma completa o no se cum-plen.

Otros conceptos fundamentales son los de error, fallo y defecto software. Se define formal-mente error como la discrepancia entre un valor o condicin calculado, observado o medido y elvalor o condicin especfica o tericamente correcta. Es un fallo que comete el desarrollador.Defecto tcnico es la desviacin en el valor esperado para una cierta caracterstica. Defecto decalidad. Desviacin de estndares y, finalmente, fallo es la consecuencia de un defecto. En mu-chas ocasiones estos trminos se confunden y se utiliza uno de ellos de forma genrica.

As, un error y un defecto software (y como consecuencia un fallo) existen cuando el soft-ware no hace lo que el usuario espera que haga, es decir, aquello que se ha acordado previa-mente en la especificacin de requisitos. En una gran parte de los casos, esto se produce por unerror de comunicacin con el usuario durante la fase de anlisis de requisitos o por un error decodificacin.

Se listan seguidamente un conjunto de principios bsicos para llevar a cabo el proceso depruebas de forma efectiva y con xito:

Las pruebas de cdigo estn muy ligadas al diseo realizado del sistema. De hecho, paragenerar los casos de prueba hay que basarse en el diseo observando tanto el diseo de loscomponentes u objetos como de la integracin de stos que componen el sistema com-

El objetivo de las pruebas es, por tanto, descubrir los errores y fallos cometidos durante las fasesanteriores de desarrollo del producto.

2 PRUEBAS DE SOFTWARE Y JUNIT. UN ANLISIS EN PROFUNDIDAD Y EJEMPLOS PRCTICOS

CAP-01 25/10/07 11:00 Pgina 2

pleto. Por ello, es conveniente definir la mayor parte de los casos de prueba y, al menos,esbozar el plan de pruebas en la fase de diseo.

Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error o fa-llo no descubierto hasta entonces. Por tanto, la prueba tiene xito si descubre un error o unfallo no detectado hasta entonces. As que es fundamental seleccionar de forma adecuadael conjunto de casos de pruebas que se va a utilizar y seguir las tcnicas correctas para ela-borar un juego de ensayo que permita obtener el objetivo mencionado.

La definicin del resultado esperado del programa es una parte integrante y necesaria deun caso de prueba. Es imprescindible conocer el resultado esperado de la prueba que seest llevando a cabo para poder discernir si el resultado obtenido es el correcto o no. Eneste sentido, hay que inspeccionar cuidadosamente el resultado de cada prueba. Tpica-mente y como se ver a lo largo de este libro, la forma de comprobar resultados esperadoses mediante la definicin de condiciones a verificar sobre los resultados obtenidos.

Un programador debe evitar probar su propio programa. De forma natural, un programa-dor tiende a no encontrar los errores en su propio cdigo. Normalmente, el ser humanopercibe una gran parte de su valor como persona asociado a la calidad de su trabajo. Es porello que inconscientemente tiende a pasar por alto los errores de su cdigo. Es mucho msefectivo que el grupo de pruebas est compuesto, por una parte, por programadores no in-volucrados en la fase de codificacin del proyecto y, por otra, por un conjunto de poten-ciales usuarios con el rol ms similar posible al perfil del usuario real.

Los casos de prueba deben ser escritos tanto para condiciones de entrada vlidas y espe-radas como para condiciones invlidas e inesperadas. Ms an, examinar un programa paracomprobar si hace o no lo que se supone que debe hacer es slo la mitad del trabajo. Tam-bin hay que comprobar que no haga aquello que se supone que no debe hacer y que loserrores y fallos estn controlados.

Hay que tener en cuenta que la probabilidad de encontrar errores adicionales en una funcindel programa o mtodo de una clase es proporcional al nmero de errores ya encontrados enesa misma funcin o mtodo. Esto deriva en que cuanto ms se modifiquen los elementospresentes en el cdigo fuente de un una funcin o programa, ms hay que probarlo.

Es imprescindible documentar todos los casos de prueba. Esto permite, por una parte, co-nocer toda la informacin sobre cada caso de prueba y, por otra, volver a ejecutar en el fu-turo aquellos casos que sean necesarios (pruebas de regresin).

1.2.1. Verificacin y validacinOtros conceptos importantes para el entendimiento del texto de este libro son los de validaciny verificacin, que se definen a continuacin en esta seccin.

La verificacin comprueba el funcionamiento del software, es decir, asegura que se imple-mente correctamente una funcionalidad especfica. En definitiva, responde a la pregunta se haconstruido el sistema correctamente?

Por su parte, la validacin comprueba si los requisitos de usuario se cumplen y los resultadosobtenidos son los previstos. Responde a la pregunta se ha construido el sistema correcto?

Ambos conceptos se usarn ampliamente a lo largo de los siguientes captulos.

FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE 3

CAP-01 25/10/07 11:00 Pgina 3

1.3. Tareas bsicasLas tareas principales que hay que realizar en la etapa de pruebas son:

1. Diseo del plan de pruebas. Esta tarea, como ya se ha mencionado, debe realizarse en lafase de diseo dentro del ciclo de vida de un proyecto software. Pero, en muchas oca-siones, esto no ocurre y se lleva a cabo en la fase de pruebas. En este caso, debe hacer-se al principio de la etapa de pruebas. El plan de pruebas consta de la planificacin tem-poral de las distintas pruebas (cundo, cmo y quin va a llevarlas a cabo), definicin dela estrategia de pruebas (ascendente, descendente, sndwich, etc.), procedimiento a se-guir cuando una prueba no obtiene el resultado esperado, asignacin de responsabili-dades, etc. Al final de este captulo se ofrece un esquema a modo de ejemplo de un plande pruebas estndar.

2. Diseo de casos de prueba. En esta fase se definirn los casos de prueba de tal formaque con un nmero de casos cuidadosamente seleccionados se realice un nmero depruebas que alcancen el nivel de cobertura1 deseado. El diseo de casos de prueba se de-tallar ms adelante en este captulo.

3. Prueba. Se lleva a cabo la escritura del cdigo de pruebas encargado de la ejecucin delos casos de prueba anteriormente diseados. Posteriormente, se realiza la ejecucin dela prueba propiamente dicha 2.

4. Comparacin y evaluacin de resultados. Teniendo en cuenta los resultados esperados,se comparan stos con los obtenidos. Si son iguales, la prueba se considera vlida, si noes as se aplican los procedimientos definidos en el plan de pruebas.

5. Localizacin del error. En el caso en el que la ejecucin de ciertos casos de prueba pro-duzca resultados no esperados, es necesario encontrar el segmento de cdigo fuente enel que se encuentra el error. Actualmente existen herramientas capaces de proporcionaral desarrollador la localizacin exacta en el cdigo fuente de los errores detectados.Como se ver en el Captulo 2, la herramienta JUnit es un gran aliado al respecto. Sinembargo, en ocasiones hay errores que son detectados en zonas del cdigo diferentes alas zonas en que se producen, en estos casos las herramientas de depuracin son de granayuda. El proceso de depuracin se lleva a cabo mediante herramientas automticas yconsiste en ejecutar el programa y detenerlo en un punto determinado cuando se cum-plan ciertas condiciones o a peticin y conveniencia del programador. El objetivo de estainterrupcin es que el programador examine aspectos tales como las variables o las lla-madas que estn relacionadas con el error o que ejecute partes internas de una funcin oincluso las sentencias de forma independiente. Se dedica una breve seccin de este ca-ptulo a la depuracin del cdigo. Para localizar el error tambin se puede acudir a lasinspecciones de cdigo que se describen a continuacinen en el Apartado 1.4 de este ca-ptulo.


1 En el Captulo 6, Generacin de informes sobre las pruebas, se presenta una herramienta capaz de generar au-tomticamente informes de cobertura. Estos informes son un indicador de la calidad de los casos de prueba diseadosy puede utilizarse para la monitorizacin y reasignacin de recursos durante la fase de pruebas.

2 Como se ver a lo largo del Captulo 2, JUnit es una herramienta ideal para asistir en la creacin y ejecucin delcdigo de pruebas. En general, esta herramienta permite automatizar todos las tareas posteriores al diseo de los casosde prueba.

CAP-01 25/10/07 11:00 Pgina 4

En las siguientes secciones se define la actividad de inspeccin de cdigo como tcnica depruebas no basada en el ordenador y la tcnica basada en ordenador: caja blanca y caja negra.

1.4. Inspecciones de cdigoLas inspecciones de cdigo, en caso de llevarse a cabo, suelen realizarse por un equipo que in-cluye personas ajenas al proyecto, participantes en otras fases del proyecto y personal del grupode calidad. Consisten en la revisin de los listados de programas y el resultado que producen esun registro de los errores encontrados. En algunos casos se ha demostrado que con las inspec-ciones de cdigo se pueden encontrar ms del 80% de los errores cometidos a pesar de no sermuy comn la aplicacin de esta tcnica. El motivo es que se trata de una tcnica no automati-zable ya que debe ser realizada por una persona. Esto es un gran inconveniente ya que multiplicael coste de las pruebas de regresin, especialmente durante la fase de mantenimiento del pro-ducto.

1.5. Pruebas basadas en la ejecucin del cdigo:tcnicasEn esta categora se incluyen las denominadas pruebas de caja blanca y pruebas de caja negraque se describen a continuacin.

1.5.1. Pruebas de caja blancaEstas pruebas se centran en probar el comportamiento interno y la estructura del programa exa-minando la lgica interna, como muestra la Figura 1.1. Para ello:

Se ejecutan todas las sentencias (al menos una vez). Se recorren todos los caminos independientes de cada mdulo. Se comprueban todas las decisiones lgicas. Se comprueban todos los bucles.Finalmente, en todos los casos se intenta provocar situaciones extremas o lmites.


Figura 1.1. Lgica interna de un programa.

CAP-01 25/10/07 11:00 Pgina 5

Ntese que al utilizar tcnicas de caja blanca se est llevando a cabo una verificacin del c-digo. Por lo tanto, ste tiene que estar disponible para la realizacin de este tipo de pruebas.

En los siguientes apartados se describen las tcnicas de caja blanca ms habituales.

1.5.1.1. Pruebas de interfaces entre mdulos o clasesEste tipo de prueba analiza el flujo de datos que pasa a travs de la interfaz (tanto interna comoexterna) del mdulo (en un lenguaje de programacin estructurada) o la clase (en un lenguajeorientado a objetos) objetivo de la prueba. Se distingue entre interfaces internas y externas.

En las pruebas de interfaces internas entre funciones o mtodos es necesario comprobar quelos argumentos de llamadas a funciones y la consistencia de las definiciones de variables glo-bales entre los mdulos. Las pruebas de interfaces internas corresponden al conjunto de pruebasunitarias, que estn enfocadas a verificar el correcto funcionamiento de un mdulo o clase ais-ladamente del resto.

Para probar adecuadamente las interfaces externas se ha de verificar que el flujo de datos in-tercambiado entre clases o mdulos es el correcto. Este tipo de pruebas es una parte de las prue-bas de integracin.

1.5.1.2. Prueba de estructuras de datos locales

Estas pruebas aseguran la integridad de los datos durante todos los pasos de la ejecucin del m-dulo. Se comprueban las referencias de datos, la posible utilizacin de variables no inicializadas,no salirse del lmite de matrices o vectores, la correcta declaracin de datos y el hecho de norealizar comparaciones entre variables de distinto tipo, como aspectos ms importantes. Ademsse localizan errores derivados del uso de variables, tales como overflow, underflow, divisin porcero, etc.

1.5.1.3. Prueba del camino bsicoSe definen para este tipo de pruebas un conjunto bsico de caminos de ejecucin usando unamedida calculada previamente de la complejidad del modulo llamada complejidad ciclomtica,propuesta por McCabe, que se basa en el grafo de flujo. La Figura 1.2 representa los grafos delos distintos caminos bsicos.

La complejidad ciclomtica indica el nmero de caminos bsicos a probar y responde a la si-guiente frmula:

V(G)AristasNodos2

Los pasos a seguir para realizar las pruebas de camino bsico son:

1. Dibujar el grafo de flujo.2. Determinar la complejidad ciclomtica del grafo.3. Determinar los caminos linealmente independientes.4. Preparar los casos de prueba que forzarn la ejecucin de cada camino.


CAP-01 25/10/07 11:00 Pgina 6

Existen correlaciones entre la complejidad de un mdulo y el nmero de errores en el m-dulo, el tiempo para encontrar errores, el esfuerzo de prueba y el esfuerzo de mantenimiento.As, un mdulo con complejidad ciclomtica mayor de 10 debe ser examinado para posiblessimplificaciones o contemplar la posibilidad de partirlo en varias subrutinas.

Se muestra, a continuacin, un ejemplo de este mtodo de pruebas.public int MCD(int x, int y) {

while (x != y) // a{

if (x > y) // bx = x - y; // c

else y = y - x; // d

} // e

return x; // f}

Seguidamente, se realiza el grafo correspondiente,

fa

b

d

e

c

7

3

546

2

1


Simple Condicin Bucle White Condicin, Do Case

Figura 1.2. Caminos bsicos.

CAP-01 25/10/07 11:00 Pgina 7

Y se halla la complejidad ciclomtica: V(G) Aristas Nodos 2. En este caso,V(MCD) 7623. La complejidad ciclomtica en este caso es 3, lo que significa que haytres caminos linealmente independientes.

La Tabla 1.1 muestra los tres posibles caminos hallados con los valores correspondientes dex y de y, as como el valor de retorno para cada uno de ellos.

Para seguir completando las pruebas con tcnicas de caja blanca, es necesario ejecutar laspruebas de bucles que se describen a continuacin.

1.5.1.4. Pruebas de condiciones lmiteEn primer lugar es necesario representar de forma grfica los bucles para, posteriormente, vali-dar la construccin de los bucles, que pueden ser simples, anidados, concatenados y no estruc-turados. Ntese que estas clasificaciones no son excluyentes entre s.

A continuacin se describe la forma ptima de tratar cada tipo de bucle para ejecutar laspruebas de condiciones.


Tabla 1.1. Caminos hallados.

1 2 3 4 5 6 7 Caso de Pruebaaf 0 0 0 0 0 0 1 x1, y1, ret1abdeaf 1 0 1 0 1 1 1 x1, y2, ret1abceaf 1 1 0 1 0 1 1 x2, y1, ret1

No estructuradosNo estructuradosConcatenadosAnidadosSimples

Figura 1.3. Tipos de bucles.

CAP-01 25/10/07 11:00 Pgina 8

Para los bucles simples, siendo n el nmero mximo de pasos, hay que realizar las siguien-tes iteraciones, con sus correspondientes pruebas para garantizar que cada tipo de bucle quedaadecuadamente probado:

Pasar por alto el bucle. Pasar una sola vez. Pasar dos veces. Hacer m pasos con mn. Hacer n1, n y n1 pasos.

En el caso de los bucles anidados, se comienza por el bucle ms interno progresando haciafuera.

Los bucles concatenados pueden ser independientes. En este caso, se realizan las mismaspruebas que si fueran de bucles simples. En el caso de que no sean independientes, se aplica elenfoque de los bucles anidados.

Los bucles no estructurados necesitan ser rediseados ya que comprometen la calidad del di-seo y, una vez hecho esto, se tratan como el tipo de bucle que haya resultado. A da de hoy,aunque instrucciones como goto todava forman parte de muchos lenguajes de programacin,la programacin no estructurada en lenguajes de alto nivel est completamente desaconsejada.Un cdigo no estructurado es difcil de leer y, por tanto, difcil de mantener.

1.5.1.5. Pruebas de condicinLas condiciones en una sentencia pueden ser, esencialmente, simples o compuestas. Una con-dicin simple puede ser una variable lgica (TRUE o FALSE) o una expresin relacional de lasiguiente forma:

E1 (operador relacional) E2,donde E1 y E2 son expresiones aritmticas y el operador relacional es del tipo, , , , , ?#.

Las condiciones compuestas estn formadas por varias condiciones simples, operadores l-gicos del tipo NOT, AND, OR y parntesis.

Los errores ms comunes que se producen en una condicin y que, por tanto, hay quecomprobar son:

Error en el operador lgico: que sean incorrectos, desaparecidos, sobrantes, etc. Error en la variable lgica. Error en la expresin aritmtica. Error en el operador relacional. Error en los parntesis.

En las decisiones, es necesario hacer pruebas de ramificaciones, que consisten en probar larama verdadera y la rama falsa y cada condicin simple.


CAP-01 25/10/07 11:00 Pgina 9

En general, existen los siguientes tipos de pruebas relacionadas con las condiciones y deci-siones:

De cobertura de decisin. De cobertura de condicin. De cobertura de decisin/condicin.

El siguiente ejemplo define los casos de prueba aplicando las coberturas de decisin y de de-cisin/condicin a partir de este fragmento de cdigo:

public void comprobarHora(int h, int m, int s) {

iif ((h >= 0) && (h = 0) && (m = 0) && (s

Caso de prueba 2: D1 Verdadero; D2 Verdadero; D3 Falsoh10; m30; s70

Caso de prueba 3: D1 Verdadero; D2 Falsoh10; m60

Caso de prueba 4: D1 Falsoh24

Se generan seguidamente los casos de prueba necesarios para obtener una cobertura com-pleta de decisin/condicin.

En el cdigo hay tres decisiones. Cada una de ellas comprende dos condiciones.

D1 (h0) and (h23)C1.1 h0C1.2 h23

D2 (m0) and (m59)C2.1 m0C2.2 m59

D3 (s0) and (s59)C3.1 s0C3.2 s59

Hay que garantizar que cada condicin tome al menos una vez el valor verdadero y otra elvalor falso, garantizando adems que se cumpla la cobertura de decisin. Los datos concretospara los casos de prueba podran ser los siguientes:

Si se utilizan los datos de C11 y C12 que hacen que tomen los valores VERDADERO si-multneamente, la decisin D1 tomar tambin el valor VERDADERO. Para que tome el valorFALSO, no se puede hacer que C11 y C12 tomen los valores FALSO simultneamente, y habrque considerar dos casos: C11V, C12F y C11F, C12V para que la decisin D1 tometambin el valor FALSO cubriendo todas las condiciones.

Lo mismo ocurre con C2.1 y C2.2 y con C3.1 y C3.2.

Caso de prueba 1: C1.1 Verdadero, C1.2 Verdadero, C2.1 Verdadero, C2.2 Ver-dadero, C3.1 Verdadero, C3.2 Verdaderoh10; m30; s50


Valor Verdadero Valor FalsoC1.1 h10 h1C1.2 h10 m24C2.1 m30 m1C2.2 m30 m60C3.1 s50 s1C3.2 s50 s70

CAP-01 25/10/07 11:00 Pgina 11

Caso de prueba 2: C1.1 Verdadero, C1.2 Verdadero, C2.1 Verdadero,C2.2 Verdadero, C3.1 Verdadero, C3.2 Falsoh10; m30; s70

Caso de prueba 3: C1.1 Verdadero, C1.2 Verdadero, C2.1 Verdadero,C2.2 Verdadero, C3.1 Falso, C3.2 Verdaderoh10; m30; s1

Caso de prueba 4: C1.1 Verdadero, C1.2 Verdadero, C2.1 Verdadero, C2.2 Falsoh10; m30

Caso de prueba 5: C1.1 Verdadero, C1.2 Verdadero, C2.1 Falso, C2.2 Verdaderoh10; m1

Caso de prueba 6: C1.1 Verdadero, C1.2 Falsoh10

Caso de prueba 7: C1.1 Falso, C1.2 Verdaderoh1

1.5.2. Pruebas de caja negraLas pruebas de caja negra estn conducidas por los datos de entrada y salida. As, los datos deentrada deben generar una salida en concordancia con las especificaciones considerando elsoftware como una caja negra sin tener en cuenta los detalles procedimentales de los progra-mas.

Las pruebas consisten en buscar situaciones donde el programa no se ajusta a su especifi-cacin. Para ello, es necesario conocer de antemano la especificacin o salida correcta y gene-rar como casos de prueba un conjunto de datos de entrada que deben generar una salida en con-cordancia con la especificacin. Cada vez que se genera una salida es necesario cuestionarse sila salida resultante es igual a la salida prevista. Si es as, se puede continuar con la siguienteprueba. Si no, se ha hallado un error que habr que investigar y corregir antes de continuar conel proceso de pruebas.

Las dos tcnicas ms comunes de las pruebas de caja negra son la tcnica de particinde equivalencia y la de anlisis de valores lmites, que se explican en las siguientes seccio-nes.


Entrada Salida

Figura 1.4. Esquema de pruebas de caja negra.

CAP-01 25/10/07 11:00 Pgina 12

1.5.2.1. Particin de equivalenciaDado que es imposible realizar pruebas que contemplen absolutamente todos los casos y cami-nos posibles, el propsito de esta tcnica y la siguiente es cubrir las pruebas de la forma ms am-plia posible diseando y utilizando un nmero de casos de prueba manejable. Para ello, en pri-mer lugar y como objetivo de la particin de equivalencia, se divide la entrada de un programaen clases de datos de los que se puedan derivar casos de prueba para reducirlos.

As, se toma cada valor de entrada y se divide en varios grupos utilizando las siguientes re-comendaciones:

Si la entrada es un rango, se define una clase de equivalencia vlida y dos invlidas. Si la entrada es un valor especfico, se define una clase de equivalencia vlida y dos in-

vlidas. Si la entrada es un valor lgico, se define una clase de equivalencia vlida y otra invlida.

1.5.2.2. Anlisis de valores lmiteDespus de haber definido y probado las distintos casos siguiendo la tcnica de particin deequivalencia, se prueban los valores lmite de cada clase de equivalencia, es decir, los valoresfronterizos de cada clase por ambos lados.

En el ejemplo mostrado en la siguiente seccin se utiliza esta tcnica. En dicha seccin semuestra la estrategia a seguir para definir de forma ms ptima el conjunto de casos de pruebaque se va a utilizar de tal forma que se hagan las pruebas de la forma ms amplia posible dentrodel lmite de recursos que se tiene.

1.6. Diseo de casos de pruebaDado que, como ya se ha mencionado, es inviable probar todos los posibles casos de prueba quecabra definir para un sistema software dado, el objetivo para realizar un buen diseo de casos escrear un subconjunto de los casos de prueba que tiene la mayor probabilidad de detectar el ma-yor nmero posible de errores y fallos.

Esto se realiza aplicando, en primer lugar, las tcnicas de caja negra y despus completarcreando casos suplementarios que examinen la lgica del programa, es decir, de caja blanca.

En particular, la estrategia habitual para conseguir este propsito sigue los pasos enumeradosa continuacin:

Aplicar anlisis del valor lmite. Disear casos con la tcnica de particin de equivalencia.

El propsito de una buena estrategia de pruebas es crear un conjunto de casos que tengan unaalta probabilidad de encontrar errores en el software, pero que supongan un esfuerzo manejablepara el ingeniero de software. El objetivo es alcanzar un grado de cobertura suficiente sobre elcdigo a probar minimizando los recursos empleados para ello.


CAP-01 25/10/07 11:00 Pgina 13

Utilizar la tcnica de conjetura de error: Combinar las entradas. Incluir casos tpicos de error (por ejemplo, 0 en la entrada o salida, listas vacas, listas

de un elementos, etc.), tambin llamado heurstica de malicia, de la que se hablar unpoco ms adelante.

Usar tcnicas de caja blanca (para pruebas unitarias, como se ver ms adelante o para fun-ciones especialmente crticas): Ejecutar cada sentencia al menos una vez. Invocar cada subrutina al menos una vez. Aplicar cobertura de decisin. Asignar a cada decisin al menos una vez un resultado

verdadero y otro falso. Aplicar cobertura de decisin/condicin. Asignar a cada condicin al menos una vez

un resultado verdadero y otro falso. Probar los bucles.

La heurstica de malicia consiste en probar con casos tpicos de error no comprendidos en loscasos generados pero susceptibles de provocar un error, como por ejemplo los datos fronterizos.Por ejemplo, el cero como valor es un buen candidato que se debe utilizar como caso de pruebao como parte de uno. Para los casos de ficheros con listas o simplemente listas, conviene probar:

Listas vacas. Listas de un elemento. Listas de n1, n y n1 elementos, siendo n el nmero mximo de elementos de la lista.

Adems, en el caso, por ejemplo de una funcin que aada elementos a una lista es intere-sante agregar datos a las listas de la siguiente forma:

Aadir un elemento a una lista vaca. Aadir un elemento cualquiera al principio de una lista unitaria, es decir, de un elemento. Aadir un elemento cualquiera al final de una lista unitaria. Aadir un elemento igual al existente en una lista unitaria. Aadir un elemento al principio de una lista de al menos tres elementos. En este caso se

trata de comprobar el funcionamiento de los punteros. As, se asegura que el segundo delos elementos de esta lista tendr punteros al elemento anterior y al siguiente, que el pri-mero de los elementos dispondr de punteros al siguiente y que el ltimo y tercero de loselementos tendr como puntero nicamente al anterior.

Aadir un elemento al final de una lista de al menos tres elementos. Por el mismo motivoque el caso anterior.

Aadir un elemento en el medio de una lista de al menos seis elementos. Este caso tienecomo fin, nuevamente comprobar el uso de punteros en un caso un poco ms complejo quela lista de tres pero que genera casos de prueba diferentes. El mtodo consiste en hacerpruebas introduciendo datos con el mismo fin que para la lista de tres elementos, es decir,


CAP-01 25/10/07 11:00 Pgina 14

al principio y al final de la misma. Tambin es interesante aadir un elemento justo en me-dio de los seis datos de la lista.

En cualquier caso, para que el mtodo de generacin de casos de pruebas sea eficiente esnecesario que el nmero de casos no se dispare explotndose de forma combinatoria y que elesfuerzo necesario para llevar a cabo esta tarea sea manejable.

La siguientes clases Java representan respectivamente un puesto determinado en el organi-grama de una empresa y el cdigo de error obtenido al dar de alta un empleado en la base de da-tos de empleados de la empresa.

public class Puesto {

public static final int ERROR_CONNECT_BD -1;public static final int MAL_NOMBRE -2public static final int MAL_DESPACHO -3public static final int MAL_PUESTO -4public static final int MAL_SUELDO -5public static final int MAL_EDAD -6}

Public class CodigoError {

public static final String JEFE_AREA = JEFE_AREA;public static final String DIRECTOR_COMERCIAL = DIRECTOR_COMERCIAL;public static final String JEFE_PROYECTO = JEFE_PROYECTO;public static final String ANALISTA = ANALISTA;public static final String PROGRAMADOR = PROGRAMADOR;}

El siguiente mtodo se encarga de dar de alta un empleado (registro) en la base de datos deempleados.

public int Alta (char nombre[256], char despacho [5], Puesto p, intedad, double sueldo_neto, double * retencion );

Esta funcin da de alta un registro en la base de datos. Los parmetros de entrada del mto-do son los siguientes:

Nombre: nombre del empleado, cadena de letras o espacios (no nmeros, ni caracteres asciique no sean letras), de longitud en el intervalo [4...255].Despacho: despacho asignado, el primer carcter es A o B, los tres siguientes son nmeros.

P: El puesto asignado, de acuerdo al tipo enumerado Puesto

Edad: Edad del empleado, nmero en el intervalo [18..., 67].Sueldo_neto: Sueldo neto mensual del empleado, en el intervalo [1000...6000]Retencin: parmetro de salida con el clculo de la retencin a efectuar. Esta se calcula de lasiguiente forma:


CAP-01 25/10/07 11:00 Pgina 15

Si el sueldo est entre 1000 y 2000 (incluido) entonces la retencin es del 8.0. La retencinsube 1,5 cada 1000 euros. Adems, dependiendo del puesto (debido a las primas), hay queaadir las siguientes cantidades: si el puesto es jefe de rea, se aade un 3.5, si es director co-mercial un 3, si es jefe de proyecto y la edad es mayor que 30, un 2. Analistas y programa-dores no tienen primas.

La funcin devuelve los cdigos definidos (de 1 a 5) en caso de error, o 1 si todo ha idobien. El orden de comprobacin de errores en los parmetros es el indicado en los defines.

Las clases vlidas y las invlidas para cada dato siguiendo la tcnica de caja negra son:

Se presentan en la siguiente pgina los correspondientes casos de prueba utilizando lasclases de equivalencia especificadas anteriormente componiendo los casos con valores vlidosy no vlidos, as como el resultado generado por cada caso como parte integrante del mismo.


Dato Clase vlida Clase no vlidaConectividad S No

Slo letras o espacios Contiene caracteres de letras

Nombreo espacios

4 longitud 255longitud 4longitud 255

Annn 1.er carcter A o BBnnn 2., 3., 4. caracters nmeroDespacho

Longitud 4longitud 4longitud 4

cadena {JEFE_AREA, cadena {JEFE_AREA.DIRECTOR_COMERCIAL DIRECTOR_COMERCIAL,Puesto JEFE_PROYECTO, ANALISTA JEFE_PROYECTO,PROGRAMADOR} ANALISTA, PROGRAMADOR}

Edad [18,67] 18 67

Sueldo neto [1000...6000] 1000 6000

*0,08 si sueldo [1000...2000]*0,095 si sueldo (2000...3000]*0,11 si sueldo (31000...4000]*0,125 si sueldo (4000...5000]

Retencin *0,14 si sueldo (5000...6000] Cualquier otro valor 3,5% si puesto JA 3% si puesto DC 2% si puestp JP y edad > 30 0 en otro caso

Cdigo error 1 1, 2, 3, 4, 5, 6

CAP-01 25/10/07 11:00 Pgina 16


SALI

DAEN

TRA

DA

Cd

igo

erro

rR

eten

cin

Con

ectiv

idad

Nom

bre

Des

pach

oPu

esto

Suel

do n

eto

Edad

ERRO

R_CO

NN

ECT_

BD

No

MA

L_N

OM

BRE

S

Lui3

Alo

nso

MA

L_N

OM

BRE

S

Lui

MA

L_N

OM

BRE

S

Artu

ro

(ms

de 25

5)

MA

L_D

ESPA

CHO

S

Juan

Lp

ezZ3

21

MA

L_D

ESPA

CHO

S

Alb

erto

Pr

ezA

B35

MA

L_D

ESPA

CHO

S

Luisa

Rui

zB

12

MA

L_D

ESPA

CHO

S

Ana

Bla

nco

A34

56

MA

L_PU

ESTO

S

Ana

Bla

nco

B34

5CO

MER

CIA

L

MA

L_SU

ELD

O

SA

na B

lanc

oB

345

JEFE

_ARE

A99

9

MA

L_SU

ELD

O

SLu

is A

lons

oA

792

DIR

ECTO

R_CO

MER

CIA

L60

01

MA

L_ED

AD

S

Ana

Bla

nco

B34

5PR

OG

RAM

AD

OR

1900

17

MA

L_ED

AD

S

Ana

Bla

nco

B34

5JE

FE_P

ROY

ECTO

4200

68

110

01*0

,08

SPe

pe P

rez

A23

4PR

OG

RAM

AD

OR

1001

56

120

01*0

,095

SSa

ntia

go A

ler

B56

7A

NA

LIST

A20

0143

130

01*(0

,11

2)S

Alb

erto

Rui

zB

345

JEFE

_PRO

YEC

TO30

0131

130

01*0

,11

SA

lber

to R

uiz

B34

5JE

FE_P

ROY

ECTO

3001

30

140

01*(0

,125

3)S

Juan

lva

rez

A79

2D

IREC

TOR_

COM

ERCI

AL

4001

55

150

01*(0

,14

3,5)

SA

na G

mez

A23

4JE

FE_A

REA

5001

67

CAP-01 25/10/07 11:00 Pgina 17

Es importante sealar que adems de las clases vlidas y no vlidas, es necesario probar conlos valores fronterizos cuando un parmetro pueda tomar un rango de valores. Por ejemplo, si unparmetro puede tomar valores de 1 a n, habr que probar con las cadenas de los siguientes ca-racteres: 0, 1, 2, n1, n y n1.

Como se ver a lo largo de este texto y, en particular, en el Captulo 8 (Mejora de la mante-nibilidad mediante JTestCase), es posible ahorrar tiempo en la definicin de los casos de prue-ba utilizando el formato XML de JTestCcase. Adems, utilizando esta herramienta se garantizaque la definicin de un caso de prueba es nica y entendible por la herramienta y el diseador.Por otra parte, la ventaja de definir los casos de prueba en XML segn el formato de dicha he-rramienta (JTestCase) es que se evita tener que escribirlos por duplicado en otros documentos.En este sentido, basta con hacer una descripcin del caso de prueba y asignarle un identificadorde forma que la definicin en detalle del caso de prueba (entradas salidas y condiciones a veri-ficar) se encuentre en un archivo XML que tiene la ventaja de ser legible por las personas (equi-po de pruebas) y por el cdigo de pruebas.

1.7. Estrategia de pruebasEsta seccin explica cul es la estrategia adecuada para llevar a cabo las pruebas en todo el sis-tema software de tal forma que finalice la fase con la satisfaccin de los ingenieros de softwarey de los usuarios. As, para realizar una buena estrategia de pruebas que cubra todo el softwaredesarrollado, es necesario realizar las pruebas desde dentro hacia fuera, es decir, comenzar conmdulos unitarios y acabar con el sistema completo.

Las pruebas que se realizan para conseguir llevar a cabo la estrategia completa se enumerana continuacin y se desarrollan en los captulos siguientes.

Pruebas unitarias. Se comprueba la lgica, funcionalidad y la especificacin de cada m-dulo o clase aisladamente respecto del resto de mdulos o clases.

Pruebas de integracin. Se tiene en cuenta la agrupacin de mdulos o clases y el flujo deinformacin entre ellos a travs de las interfaces.

Pruebas de validacin. Se comprueba la concordancia respecto a los requisitos de usuarioy software.

Pruebas del sistema. Se integra el sistema software desarrollado con su entorno hardwarey software.

Pruebas de aceptacin. El usuario valida que el producto se ajuste a los requisitos del usua-rio.

La estrategia de pruebas descrita se representa en la Figura 1.5. Lo que se pretende con estaestrategia es obtener una estabilidad incremental del sistema software. Sin embargo, hay quedestacar que cada nivel de prueba se corresponde con una fase del proceso de desarrollo del pro-

Es importante comprobar el resultado generado por cada fase del ciclo de vida de un proyecto desoftware antes de pasar a la siguiente fase. De este forma, no se arrastran errores cuyo coste decorreccin ser mayor cuanto ms tarde se detecten.


CAP-01 25/10/07 11:00 Pgina 18

ducto software, correspondiendo los niveles ms altos de las pruebas a las primeras fases deldesarrollo, como se representa en la Figura 1.6. Esto deriva directamente en el hecho de que el


Informacinde diseo

Requisitosde usuario

Requisitos softwarey del sistema

Otros elementosdel sistema

Criterios deaceptacindel usuario(o contrato)

Pruebas deintegracin

Pruebas devalidacin

Pruebas delsistema

Pruebas deaceptacin

Software de validacin

Software integrado

Entorno deprogramacin

Entorno dedesarrollo

Entorno deusuario

.... .... .... ....

Pruebasde

unidad

Pruebasde

unidad

Pruebasde

unidad

Mdulo/Objeto Mdulo/Objeto Mdulo/Objeto

Figura 1.5. Estrategia de pruebas.

Pruebas delsistema

Pruebas deaceptacin

Pruebas devalidacin

Pruebas deintegracin

Pruebas deunidadCodificacin

Diseodetallado

Diseo dearquitectura

Requisitossoftware

Requisitosdel sistema

Requisitosde usuario

Fases de desarrollo Proceso de pruebas

Figura 1.6. Relacin Nivel de pruebas-Fase de desarrollo.

CAP-01 25/10/07 11:00 Pgina 19

coste de encontrar y corregir un error aumenta a medida que avanzamos en la estrategia de prue-bas. As, si se detecta y corrige un error en la fase de pruebas del sistema, habr que modificarlos requisitos del sistema, los requisitos software, el diseo y el cdigo de forma consistente ycoherente.

1.7.1. Pruebas unitariasLas pruebas unitarias se corresponden con la prueba de cada uno de los mdulos o clases delprograma de forma independiente y es realizada por el programador en su entorno de trabajo. Endefinitiva, consiste en probar los bloques ms pequeos con identidad propia presentes dentrodel programa. De esta forma, si una prueba descubre un nuevo error, este est ms localizado.Adems, se pueden probar simultneamente varios mdulos.

El enfoque de las pruebas unitarias es el de las tcnicas de caja blanca. Para ello se crean m-dulos conductores y mdulos resguardo. Un mdulo conductor o mdulo impulsor es un mduloespecficamente creado para la prueba que llama al mdulo a probar. Un mdulo resguardo omdulo auxiliar es un mdulo especficamente creado para la prueba que es llamado por el m-dulo a probar, tal y como se muestra en la siguiente figura.

Se construyen, por tanto, mdulos resguardo o mdulos conductores cuya funcin es el pasode parmetros o variables o hacer las llamadas necesarias al mdulo que se desea probar de talforma que se pruebe el mdulo de forma unitaria pero con el paso de parmetros real o desdeotros mdulos. De esta forma, se prueba el mdulo en cuestin y se corrigen los errores que sur-jan de dicho mdulo, de tal manera que cuando se pase a la siguiente etapa de pruebas, los m-dulos estn todos probados de forma independiente.

En general, en un lenguaje orientado a objetos, los resguardos son llamados clases colabo-radoras y se caracterizan por mantener una relacin de asociacin con la clase a probar. En elCaptulo 7, Objetos Mock, se presentan tcnicas para la creacin de resguardos de forma com-pletamente automatizada.


Conductor

ResguardoResguardo

Mduloa probar

Casos deprueba

Resultados

Interfaz, estructuras de datos,caminos, condiciones

Figura 1.7. Esquema de pruebas unitarias.

CAP-01 25/10/07 11:00 Pgina 20

1.7.2. Pruebas de integracinEsta etapa consiste en integrar los mdulos o clases3, ya probados de forma independiente en laspruebas unitarias centrndose en probar sus interfaces. Habitualmente se utiliza el enfoque decaja negra.

La cuestin principal es determinar la manera en la que se combinan los distintos mdulos.Hay dos estrategias bsicas.

Prueba no incremental o big bang, en la que no hay un procedimiento establecido y se vanintegrando los mdulos sin ningn orden establecido. Se desaconseja totalmente.

Prueba incremental, en la que se supone un diseo en forma jerrquica o de rbol y esta-blece un orden que puede ser descendente, ascendente o sandwich. Los mdulos se van in-tegrando poco a poco con unas especificaciones establecidas. Estos tres tipos de integra-cin incremental se describen en las prximas secciones.

1.7.2.1. Pruebas de integracin ascendentesSe comienza a integrar por los mdulos terminales del rbol y se contina integrando de abajohacia arriba hasta llegar al mdulo raz. En esta estrategia se utilizan mdulos conductores y elprocedimiento bsico es el siguiente:

1. Se combinan mdulos del nivel ms bajo en grupos.2. Se construye un conductor para coordinar la E y S de los casos de prueba.3. Se prueba el grupo.4. Se eliminan los conductores sustituyndolos por los mdulos reales y se combinan los

grupos movindose hacia arriba por la estructura del programa.5. Se hacen pruebas de regresin: repetir ciertos casos de prueba que funcionaban con el

software antes de sustituir los mdulos reales para asegurar que no se introducen nuevoserrores.

1.7.2.2. Pruebas de integracin descendentesEn este caso se comienza con el mdulo superior y se contina hacia abajo por la jerarqua decontrol bien en profundidad, bien en anchura. Se utilizan mdulos resguardo.

Las fases que se siguen son:1. Se usa el mdulo de control principal como conductor de pruebas, construyendo res-

guardos para los mdulos inmediatamente subordinados.2. Se sustituyen uno a uno los resguardos por los mdulos reales.3. Se prueba cada vez que se integra un nuevo mdulo.4. Se contina reemplazando mdulos resguardo por mdulos reales hasta llegar a los no-

dos terminales.


3 En adelante, se utilizar el termino mdulo para referirse a mdulos o clases dependiendo de si el lenguaje deprogramacin es estructurado u orientado a objetos respectivamente.

CAP-01 25/10/07 11:00 Pgina 21

5. Se hacen pruebas de regresin: repetir ciertos casos de prueba que funcionaban con elsoftware antes de sustituir los mdulos reales para asegurar que no se introducen nuevoserrores.

1.7.2.3. Pruebas de integracin sandwichEsta estrategia combina las dos anteriores, es decir las aproximaciones ascendentes y descen-dentes.

De esta forma, se aplica la integracin ascendente en los niveles inferiores de la jerarqua demdulos y paralelamente, se aplica la integracin descendente en los niveles superiores de la je-rarqua de mdulos. La integracin termina cuando ambas aproximaciones se encuentran en unpunto intermedio de la jerarqua de mdulos.

1.7.2.4. Eleccin del mdulo/clase crtico/aPara decidir si se utiliza una aproximacin ascendente, una descendente o una de tipo sndwiches imprescindible investigar sobre cul es el mdulo o los mdulos ms adecuados para co-menzar a integrar. En general, los mdulos a los que se les da preferencia por ser ms propensosa contener errores son los mdulos de entrada o salida y los mdulos crticos, que son aquellosque cumplen con alguna de las siguientes caractersticas:

Est dirigido a varios requisitos del software. Tiene un nivel de control alto. Es complejo o contiene un algoritmo nuevo. Es propenso a errores. Tiene unos requisitos de rendimiento muy definidos o muy estrictos.

As, se comenzarn las pruebas por el o los mdulos que cumplan alguna de las condicionesanteriormente sealadas. Si estos se corresponden con los mdulos superiores, se utilizar unaestrategia descendente. Si, por el contrario, se trata de los mdulos inferiores, se seguir una es-trategia ascendente y si los mdulos crticos se encuentran tanto en la parte superior como en lainferior del diseo jerrquico, la aproximacin ms adecuada es la de tipo sndwich.

1.7.2.5. Acoplamiento y cohesinEl acoplamiento es una medida de la interconexin entre los mdulos de un programa. El dise-o es la fase en la que se puede y debe tener en cuenta esta medida. As, hay que tender a unbajo acoplamiento, ya que, entre otras cosas, se minimiza el efecto onda (propagacin de erro-res), se minimiza el riesgo al coste de cambiar un mdulo por otro y se facilita el entendimien-to del programa.

La cohesin mide la relacin, principalmente funcional pero no slo, de los elementos de unmdulo. Hay que conseguir un alto grado de cohesin ya que conlleva un menor coste de pro-gramacin y consecuentemente una mayor calidad del producto.

En definitiva, hay que disear haciendo que los mdulos sean tan independientes como sea po-sible (bajo acoplamiento) y que cada mdulo haga (idealmente) una sola funcin (alta cohesin).


CAP-01 25/10/07 11:00 Pgina 22

Ambas medidas tienen una gran repercusin en las pruebas, ya que facilitan las mismas tan-to a la hora de deteccin de un error, como a la hora de corregirlo y realizar las correspondien-tes pruebas de regresin.

1.7.3. Pruebas de validacinEl objetivo de las pruebas de validaci

pruebas de software y junit - daniel bolanos alonso

Documents