Definición y Aplicación de Un Método para El Desarrollo de Mundos Virtuales en Entornos Web

UNIVERSIDAD DE PAMPLONA
FACULTAD DE INGENIERIAS Y ARQUITECTURA

DEPARTAMENTO DE INGENIERIAS ELÉCTRICA ELECTRÓNICA SISTEMAS Y
TELECOMUNICACIONES
PROGRAMA DE INGENIERIA DE SISTEMAS
TEMA:
DEFINICIÓN DE UN PROCEDIMIENTO PARA LA APLICACIÓN DE PRUEBAS

EN EL DESARROLLO DE MUNDOS VIRTUALES.
AUTOR: ELLELVER ARLEYNDER MENESES JAIMES
PAMPLONA COLOMBIA
Noviembre de 2008
TELECOMUNICACIONES
TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

INGENIERO DE SISTEMAS
TEMA
AUTOR: ELLELVER ARLEYNDER MENESES JAIMES

DIRECTOR: Edgar Alexis Albornoz Espinel
PAMPLONA COLOMBIA
Noviembre de 2008
TELECOMUNICACIONES
TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

TITULO

FACULTAD DE INGENIERÍAS Y ARQUITECTURA
DEPARTAMENTO DE INGENIERÍAS ELÉCTRICA ELECTRÓNICA, SISTEMAS Y
TELECOMUNICACIONES
PROGRAMA DE INGENIERÍA DE SISTEMAS
PROYECTO DE TRABAJO DE GRADO PARA OPTAR POR EL TÍTULO DE

DEFINICIÓN DE UN PROCEDIMIENTO PARA LA APLICACIÓN DE PRUEBAS EN EL

DESARROLLO DE MUNDOS VIRTUALES.
INICIO DEL TRABAJO DE GRADO: AGOSTO DE 2008

TERMINACION DEL TRABAJO DE GRADO: OCTUBRE DE 2008
FIRMAS
__________________________________ __________________________________
Elllelver Meneses Jaimes Ing. Edgar Albornoz
AUTOR DIRECTOR.
__________________________________ __________________________________
PhD(C). Ing. CARLOS PARRA PhD Ing. Laura Villamizar
COORDINADOR DEL PROGRAMA PRESIDENTE
__________________________________ __________________________________
Ing. Luis A. Esteban Villamizar Ing. Ingrid Rojas
OPONENTE SECRETARIO
Código FGA-72 v.01
Acta de Sustentación de Trabajo de Grado
Página 1 de 1
PROGRAMA: ________________________________________________________________________________
PREGRADO POSTGRADO
EL JURADO CALIFICADOR CONFORMADO POR: (Nombres, apellidos y documento de identidad).
JURADO 1: ________________________________________________/ C.C: _______________________________
JURADO 2: ________________________________________________/ C.C: _______________________________
JURADO 3 ________________________________________________ / C.C: _______________________________
JURADO 4*: _______________________________________________/ C.C: _______________________________
EN SU SESIÓN EFECTUADA EN: ______________________________________________________________ A LAS ___________

HORAS, DEL DÍA________ DEL MES ________ DEL AÑO_________________________
Terminadas sus deliberaciones, y en cumplimiento de las normas y acuerdos de los órganos de dirección de la Universidad de Pamplona,
ha llegado a las siguientes conclusiones:
Primera Conclusión: Otorgar la Calificación de: ___.___ (Si aplica)
(PARA PREGRADO) EXCELENTE APROBADO INCOMPLETO
(*PARA POSTGRADO) APROBADO NO APROBADO
AL TRABAJO DE GRADO TITULADO:

_______________________________________________________________________________________________________________
_______________________________________________________________________________________________________________
_______________________________________________________________
AUTOR: ____________________________________________________ /C.C:_____________________

DIRECTOR: _SERGIO PEÑALOZA_______________________________ /C.C:______________________
CODIRECTOR*: _____________________________________________ /C.C:______________________
MODALIDAD (SOLO PARA PREGRADO): ___________________________________________________
Segunda Conclusión: Emitir los siguientes criterios
RECOMENDAR
No. DESCRIPCIÓN SI NO
1. Recomendar para presentar en eventos.
2. Recomendar para publicación.
3. Incluir en el fondo bibliográfico de la Universidad de Pamplona.
4. Recomendar para ser continuado en otros trabajos.
5. Recomendar para patente
6. Recomendar continuar como trabajo de maestría
7. Recomendar continuar como trabajo de doctorado.
8. Recomendar para Meritorio.
9. Recomendar para Laureado
Otras:__________________________________________________________________________________________________________
_______________________________________________________________________________________
Tercera Conclusión: Avalar el cumplimiento del Trabajo de Grado, para optar por el Título de
____________________________________________________________________________________________
Firmas del Jurado Calificador:
______________________ _________________________ ____________________ ___________________

JURADO 1 JURADO 2 JURADO 3 JURADO 4*
_________________________________ ______________________________
Director Comité Trabajo de Grado Director Unidad Académica
DEDICATORIA.
Dedicado a todas aquellas personas que buscan el conocimiento, personas que

quieren mejorar y progresar con sus ideas e incentivar a buscar los caminos para
llevar esas ideas hacia adelante y poder brindar herramientas para resolver
problemas en la sociedad. El conocimiento es del mundo pero para encontrarlo
hay que emprender la búsqueda y una vez encontrado compartirlo hacia nuevas
generaciones y llevar la evolución del mundo hacia ideas cada vez más
novedosas y útiles.
AGRADECIMIENTOS.
Agradecimientos a mis padres Agustín Meneses Áreas y Emilia Jaimes Guarín por
todo el apoyo moral como económico, a mis compañeros por el trabajo en equipo,
a mis profesores por inculcar la búsqueda del conocimiento así como también por
la enseñanza de la ética, la moral y demás valores humanos los cuales deben ser
aliados para enfrentar a la universidad de la vida.
RESUMEN.
Este trabajo se da por la falta de un procedimiento de ejecución de pruebas para

el desarrollo de mundos virtuales, aunque existen muchas entidades y firmas con
demasiado dinero (EAGAMES, MICROSOFT ESTUDIO GAMES, KONAMI,
CAPCOM, NINTENDO, PLAYSTATION etc.) que poseen este conocimiento pero
aun así no lo revelan al mundo por motivos económicos.
Para definir este procedimiento de pruebas se desarrollo un estudio sobre la guía

del cuerpo del conocimiento de ingeniería de software (SWEBOK) este
procedimiento consta de tres etapas denominadas de la siguiente manera. Etapa
uno diseñador de objetos grafico, etapa dos desarrollador y la etapa tres
correspondiente a los usuarios finales.
ABSTRACT.
This work is given by the lack of an enforcement of tests of development of the
virtual worlds, although, now there are many institutions with too much money (i.e.,
EAGAMES, MICROSOFT, ESTUDIO GAMES, KONAMI, CAPCOM, NINTENDO
and PLAYSTATION, etc) that have this knowledge, but they do not divulge it to the
world because of economic reasons.
To define this test procedure was developed a study about engineer software
guide (SWEBOK). This procedure consist of three stages: the first one is “graphic
object designer”; the second one, is the “developer”; and the last one is about end
users.
ÍNDICE GENERAL
CAPITULO 1. ................................................................................................................................. 1
INTRODUCCIÓN. ......................................................................................................................... 1
1.1 JUSTIFICACIÓN. ............................................................................................................ 2
1.2 Objeto. ................................................................................................................................... 2
1.3 Necesidades y Problemas. ..................................................................................................... 2
1.4 Criterios de Viabilidad. ......................................................................................................... 3
1.5 Delimitación. ......................................................................................................................... 3
1.5.1 Objetivo General. ......................................................................................................................... 3
1.5.2 Objetivos Específicos. .................................................................................................................. 3
CAPÍTULO 2 .................................................................................................................................. 4
MARCO TEÓRICO ........................................................................................................................ 4
2.1 Niveles de Prueba.................................................................................................................. 4
2.1.1 Pruebas de Unidad. ...................................................................................................................... 5
2.1.2 Pruebas De Integración. .............................................................................................................. 5
2.1.2.1 Integración Incremental Ascendente. ................................................................................... 6
2.1.2.4 Integración Incremental Descendente. ................................................................................ 7
2.1.3 Pruebas de Sistema. ..................................................................................................................... 9
2.2 Pruebas de Aceptación. ....................................................................................................... 10
2.2.1 Ventajas de las Pruebas de Aceptación. .................................................................................... 11
2.2.2 Pruebas de Instalación. ............................................................................................................. 11
2.2.3 Pruebas de Regresión. ............................................................................................................... 12
2.2.4 Pruebas de Rendimiento. .......................................................................................................... 12
2.2.5 Pruebas de Desgaste. ................................................................................................................ 12
2.2.6 Pruebas de Continuidad. ........................................................................................................... 12
2.2.7 Pruebas de Recuperación. ......................................................................................................... 13
2.2.8 Pruebas de Facilidad de Uso. ..................................................................................................... 13
2.3 Técnicas de Prueba según guía de Ingeniería de Software Swebok. .................................. 13
2.3.1 Pruebas Basadas en la Intuición y la Experiencia del Ingeniero de Software. ........................... 13
2.3.1.1 Pruebas Ad Hoc. .................................................................................................................. 13
2.3.1.2 Pruebas por Exploración. .................................................................................................... 14
2.3.2 Técnicas Basadas en el Código. .................................................................................................. 14
2.3.2.1 Criterios Basados en el Flujo de Datos. .............................................................................. 14
2.3.2.2 Modelos de Referencia para Pruebas Basadas en el Código. ............................................ 15
2.3.3 Técnicas Basadas en Errores. .................................................................................................... 15
2.3.3.1 Conjeturar Errores. ............................................................................................................. 15
2.3.3.2 Pruebas por Mutación. ....................................................................................................... 15
2.3.4 Técnicas Basadas en el Uso. ...................................................................................................... 16
2.3.4.1 Perfil Operativo. ................................................................................................................. 16
2.3.4.2 Deterministas vs Aleatorias. .............................................................................................. 17
2.4 Medidas de las Pruebas. ..................................................................................................... 17
2.4.1 Evaluación de un Programa durante las Pruebas. ..................................................................... 18
2.4.1.2 Medidas para ayudar en la Planificación y Diseño de Pruebas de Programas. ................. 18
2.4.1.4 Densidad de Fallos. ............................................................................................................ 18
2.4.1.5 Vida de las Pruebas, Evaluación de Confiabilidad. ............................................................. 18
2.4.1.6 Modelos de Crecimiento de la Confiabilidad. .................................................................... 18
2.5 Evaluación de las Pruebas Realizadas................................................................................ 19
2.5.1 Cobertura Minuciosa de Medidas. ............................................................................................ 19
2.5.2 Introducción de Errores. ........................................................................................................... 19
2.5.3 Puntuación de la Mutación. ....................................................................................................... 20
2.5.4 Comparación y Efectividad Relativa de las Diferentes Técnicas. ............................................... 20
2.6 El Proceso de las Pruebas. .................................................................................................. 21
2.6.1 Actitudes y Programación. ........................................................................................................ 21
2.6.2 Guías para las Pruebas. ............................................................................................................. 21
2.6.3 Gestión del Proceso de las Pruebas. ......................................................................................... 22
2.6.4 Documentación y Productos de las Pruebas. ............................................................................ 22
2.6.5 Equipo de Pruebas Interno vs Equipo Independiente. ............................................................. 22
2.6.6 Estimación Coste/esfuerzo y Otras Medidas del Proceso. ....................................................... 23
2.6.7 Finalización. ............................................................................................................................... 23
2.6.8 Reutilización de pruebas y Patrones de Pruebas. ..................................................................... 24
2.7 Actividades de las Pruebas. ................................................................................................ 24
2.7.1 Planificación. ............................................................................................................................. 25
2.7.2 Generación de Casos de Pruebas. ............................................................................................. 25
2.7.3 Desarrollo en el Entorno de Pruebas. ....................................................................................... 25
2.7.4 Ejecución. .................................................................................................................................. 26
2.7.5 Evaluación de los Resultados de las Pruebas. ........................................................................... 26
2.7.6 Notificación de Problemas/Diario de Pruebas. ......................................................................... 26
2.7.7 Seguimiento de Defectos. ......................................................................................................... 27
2.8 Aspectos de las Pruebas. .................................................................................................... 27
2.8.1 Inspección de Componentes. .................................................................................................... 28
CAPITULO 3 ................................................................................................................................ 30
ANALISIS Y DEFINICION DE UN PROCEDIMEINTO DE PRUEBAS PARA
MUNDOS VIRTUALES. ............................................................................................................. 30
3.1 Planeación de las Pruebas. .................................................................................................. 30
3.2 Documentación de las Pruebas. ......................................................................................... 31
3.3 Asignación de Responsabilidades. ...................................................................................... 32
3.4 Etapas en el Proceso de Pruebas en Mundos Virtuales. ...................................................... 32
3.4.1 Etapa uno: Diseñador de Objetos Gráficos. ............................................................................... 33
3.4.1.1 Validar Objetos Según Requerimientos. ............................................................................. 34
3.4.1.2 Comprobar Poligonización. ................................................................................................. 35
3.4.1.3 Validar Animación. .............................................................................................................. 37
3.4.1.4 Verificar Exportación de Objeto. ......................................................................................... 38
3.4.1.5 Evaluación/Informes. .......................................................................................................... 39
3.4.2 Etapa Dos: Programador. .......................................................................................................... 40
3.4.2.1 Importar Objetos................................................................................................................. 40
3.4.2.2 Tiempo de Ejecución. .......................................................................................................... 41
3.4.2.3 Ejecución, Animaciones de Objetos. .................................................................................. 42
3.4.2.4 Tolerancia de Hardware. ..................................................................................................... 43
3.4.2.5 Validación de Objetos Según Requerimientos, Validar Animación y Comprobación de
Polígonos. ........................................................................................................................................ 45
3.4.2.6 Evaluación/Informes. .......................................................................................................... 45
3.4.3 Etapa Tres Usuarios de Prueba. ................................................................................................. 46
3.4.3.1 Instalación del Mundo Virtual. ............................................................................................ 47
3.4.3.2 Maniobrabilidad. ................................................................................................................. 48
3.4.3.3 Efectos Especiales. .............................................................................................................. 49
3.4.3.4 Tolerancia a Errores Externos. ............................................................................................ 50
3.4.3.5 Evaluación / Informes. ........................................................................................................ 51
CAPITULO 4 ................................................................................................................................ 53
DEMOSTRACIÓN DE EJECUCIÓN DEL PROCEDIMIENTO DE PRUEBAS A UN
MUNDO VIRTUAL LLAMADO FISMAGIC. ........................................................................... 53
4.1 Demostración Etapa Uno. ................................................................................................... 55
4.1.1 Validación Según Requerimientos. ........................................................................................... 56
4.1.2 Comprobar Poligonización. ....................................................................................................... 57
4.1.3 Valida animación. ...................................................................................................................... 57
4.1.4 Verificar Exportación de Objeto. ................................................................................................ 58
4.1.5 Evaluación / Informes. .............................................................................................................. 59
4.2 Etapa Dos Desarrolladores. ................................................................................................ 59
4.2.1 Importación de Objetos. ............................................................................................................ 60
4.2.3 Tiempo de Ejecución. ................................................................................................................. 60
4.2.4 Ejecución, Animaciones de Objetos. ......................................................................................... 61
4.2.5 Tolerancia de Hardware. ............................................................................................................ 62
4.2.6 Validación de Objetos Según Requerimientos. ......................................................................... 62
4.3 Etapa Tres Usuario de Prueba. ........................................................................................... 64
4.3.1 Instalación del Mundo Virtual. ................................................................................................... 64
4.3.2 Maniobrabilidad. ....................................................................................................................... 65
4.3.3 Efectos Visuales. ........................................................................................................................ 66
4.3.4 Tolerancia a Errores Externos. ................................................................................................... 67
MARCO LEGAL. ......................................................................................................................... 69
INFLUENCIA AMBIENTAL. ..................................................................................................... 70
CONCLUSIONES. ....................................................................................................................... 71
RECOMENDACIONES. .............................................................................................................. 72
GLOSARIO DE TÉRMINOS Y SÍMBOLOS.............................................................................. 73
BIBLIOGRAFÍA. ......................................................................................................................... 74
ANEXO I. ..................................................................................................................................... 75
Recursos Humanos. .................................................................................................................. 75
Recursos Físicos. ...................................................................................................................... 75
Recursos Económicos. .............................................................................................................. 76
Anexo 2 ......................................................................................................................................... 76
FUENTES DE FINANCIACIÓN. ............................................................................................ 76
Anexo 3. ........................................................................................................................................ 77
Plantillas para la ejecución de pruebas en mundos virtuales. ................................................... 77
ÍNDICE DE FIGURAS
Fig. 3.1 Etapa Uno Proceso de Pruebas ........................................................................................ 34
Fig. 3.2 Etapa Dos del Proceso de Pruebas ................................................................................... 40
Fig. 3.3 Etapa Tres del Proceso de Pruebas .................................................................................. 46
Fig. 3.5 Las Tres Etapas del Proceso de Pruebas. ........................................................................ 52
Fig. 4.1 Mundo Virtual FisMagic. ................................................................................................ 59
Fig. 4.2 Componente Uno Mundo Virtual FisMagic. ................................................................... 59
Fig. 4.3 Menú Principal FisMagic. ............................................................................................... 64
Fig. 4.5 Vista Polígonos de mallas Componente Uno FisMagic. ................................................. 66
ÍNDICE DE FORMULARIOS
Formulario 3.1 Validación de Pruebas Según Requerimientos .................................................... 34
Formulario 3.2 Comprobar Poligonización. ................................................................................. 36
Formulario 3.3 Validar Animación. .............................................................................................. 38
Formulario 3.4 Verificar Exportación De Objetivos..................................................................... 39
Formulario 3.5 Importación de Objetos. ....................................................................................... 41
Formulario 3.6 Tiempo de Ejecución............................................................................................ 42
Formulario 3.7 Ejecución, Animación De Pruebas....................................................................... 43
Formulario 3.8 Tolerancia de Hardware ....................................................................................... 44
Formulario 3.9 Instalación del Mundo Virtual. ............................................................................ 48
Formulario 3.10 Maniobrabilidad. ................................................................................................ 49
Formulario 3.11 Efectos Especiales. ............................................................................................. 50
Formulario 3.12 Tolerancia A Errores Externos. .......................................................................... 51
Formulario 4.1 Demostración Primer Caso de Prueba Etapa Uno................................................ 56
Formulario 4.2 Demostración Segundo Caso de Prueba Etapa Uno. ........................................... 57
Formulario 4.3 Demostración Tercer Caso de Prueba Etapa Uno. ............................................... 58
Formulario 4.4 Demostración Cuarto Caso de Prueba Etapa Uno................................................ 58
Formulario 4.5 Demostración Primer Caso de Prueba Etapa Dos. ............................................... 60
Formulario 4.6 Demostración Segundo Caso de Prueba Etapa Dos. ............................................ 60
Formulario 4.7 Demostración Tercer Caso de Prueba Etapa Dos. ............................................... 61
Formulario 4.8 Demostración Cuarto Caso de Prueba Etapa Dos. ............................................... 62
Formulario 4.9 Demostración Sexto Caso de Prueba Etapa Dos. ................................................. 63
Formulario 4.10 Demostración Primer Caso de Prueba (a) Etapa Tres. ....................................... 64
Formulario 4.11 Demostración Segundo Caso de Prueba Etapa Tres. ......................................... 65
Formulario 4.12 Demostración Tercer Caso de prueba Etapa Tres. ............................................. 66
Formulario 4.13 Demostración Cuarto Componente Etapa Tres. ................................................. 67
CAPITULO 1.
INTRODUCCIÓN.
Los módulos de multimedia han sido una verdadera bomba para el aprendizaje de
los diferentes campos estudiantiles como lo pueden ser las matemáticas, físicas,
químicas, etc.
Pero para lograr que todas estas multimedias que puedan llegar hacer muy
buenas, robustas, realistas, etc. se necesita de bastante experiencia.
Existen grandes empresas desarrolladoras de mundos virtuales muy buenas,
logrando posicionarse en el mercado y ocupar los primeros lugares en ventas y en
popularidad.
Existen también pequeñas empresas que no poseen los conocimientos que son
necesarios para llegar a competir con estos productos virtuales. Todo esto porque
las grandes empresas no revelan sus procedimientos y técnicas para lograr que
sus productos sean de muy buena calidad.
Uno de los principales problemas es la ejecución de pruebas a los mundos

virtuales, para mejorarlos, es decir poder corregir los defectos, fallas o errores que
puedan encontrarse.
Este trabajo propone un procedimiento para la ejecución de pruebas en mundos

virtuales y así poder mejorar con el tiempo y la experiencia los productos virtuales.
1
1.1 JUSTIFICACIÓN.
Teniendo en cuenta que los mundos virtuales son el futuro de los diferentes
sistemas informáticos o simuladores de realidad virtual, es muy importante saber
cuándo un mundo virtual está en óptimas condiciones, por lo que es necesario
encontrar un método de pruebas para el desarrollo de mundos virtuales.
El procedimiento de prueba nos ayuda a corroborar si existen o no errores en la

construcción de mundos virtuales, permitiéndonos de esta manera corregirlos.
Pero A medida que pasa el tiempo se adquiere más experiencia en la

determinación y ejecución de las pruebas en los mundos virtuales. Y esto puede
ayudar a ir mejorando cada vez más el procedimiento para la ejecución de
pruebas en cualquier producto de multimedia 3d.
1.2 Objeto.
Las técnicas de pruebas de software en el desarrollo de mundos virtuales.
1.3 Necesidades y Problemas.
El grupo de Investigación INTEGRAR de física de la universidad de pamplona, se

dedica a desarrollar simulaciones de física mediante mundos virtuales. Este grupo
desarrolla los mundos sin tener un método de prueba para evaluar los mundos
virtuales.
La necesidad de aplicar un método de prueba para los objetos y las simulaciones

en los mundos virtuales de física.
2
El procedimiento de prueba debe ser no solo para este grupo de desarrollo, si no
también debe ser un procedimiento general, que sea útil para cualquier persona
que desarrolle mundos virtuales y deseen evaluar sus productos 3d.
1.4 Criterios de Viabilidad.

• El autor cuenta con la preparación necesaria para enfrentar las labores
de diseño del objeto del trabajo y con los siguientes asesores calificados
y especializados en distintas áreas de acción y desarrollo.
• Ing. Edgar Albornoz. Diseño y evaluación de ambientes virtuales en
3D.
• Mg Luis Alberto Esteban. En la parte de conocimientos de ingeniería
de software.
1.5 Delimitación.
1.5.1 Objetivo General.
Definir un procedimiento para la ejecución de pruebas en el desarrollo de mundos

virtuales.
1.5.2 Objetivos Específicos.
• Estudiar y documentar diferentes técnicas de pruebas para el desarrollo de

mundos virtuales
• Plantear un procedimiento para la definición y ejecución de casos de

prueba en desarrollo de mundos virtuales
• Aplicar el procedimiento de prueba al un prototipo de mundo virtual

desarrollado.
3
CAPÍTULO 2
MARCO TEÓRICO
Ejecutar pruebas es una actividad muy importante en cualquier tipo de desarrollo

de software. Esta actividad tiene el objetivo de ajustar y optimizar la calidad del
producto identificando defectos y problemas. Las pruebas consisten en verificar el
comportamiento de un programa mediante un grupo de técnicas de pruebas. La
valoración de las pruebas es una tarea que no empieza solamente cuando la fase
de programación se ha completado, pues el propósito de las pruebas no es solo
detectar errores fallas o defectos. Las pruebas de software se ven ahora como
una actividad que debería estar presente durante todo el proceso de desarrollo y
mantenimiento, y es en sí misma una parte importante de la construcción del
producto.
La guía de ingeniería Swebok define los siguientes niveles de prueba.
2.1 Niveles de Prueba.
Las pruebas se ejecutan en diferentes niveles de desarrollo de software,

conceptualmente se pueden distinguir tres grandes niveles de pruebas, llamadas
de Unidad, de Integración y de Sistema. No hay un modelo de proceso implícito, ni
se asume que alguno de estos tres niveles tiene mayor importancia que los otros
dos.
Las pruebas de software se realizan normalmente a diferentes niveles durante los

procesos de desarrollo y mantenimiento. Esto significa que el objeto de las
4
pruebas puede cambiar: Un módulo, un grupo de dichos módulos (relacionados
por propósito, uso, comportamiento, o estructura), o un sistema completo.
Una manera de acoplar los niveles de prueba al procedimiento de pruebas para

mundos virtuales se ve reflejada según los documentos “Documentación y
pruebas antes del paradigma de objetos.” (Suárez P, Fontela C, 2003).
2.1.1 Pruebas de Unidad.
Este tipo de prueba verifica y evalúa el funcionamiento aislado de partes de

software que a su vez podrían considerarse como subprogramas individuales, o
también podríamos tener subprogramas que son partes de un componente mucho
mas grande. Normalmente las pruebas unitarias son ejecutadas por los
programadores puesto que ellos conocen de manera más detallada el código
fuente(Suárez P, Fontela C, 2003:7).
2.1.2 Pruebas De Integración.
La base fundamental de las pruebas de integración son las pruebas unitarias, y

consiste en desarrollar de manera ordenada una serie de pruebas para aquellos
módulos que van siendo ensamblados y probados hasta lograr integrar el sistema.
No es necesario terminar el proceso de pruebas unitarias para iniciar con las
pruebas de integración, también se pueden realizar estas pruebas de forma
paralela con las unitarias, todo esto depende de la forma en cómo se organicen
los módulos.
El orden de integración de los módulos influye en:
• La forma de preparar los casos de prueba.
5
• Las herramientas a utilizar.
• El orden para codificar y probar los módulos.
• El costo de preparar los casos.
• El costo de la depuración.
Tanto es así que se le debe prestar especial atención al proceso de elección del
orden de Integración que se emplee.
Existen principalmente dos tipos de integración: La integración incremental y la no

incremental. La integración incremental consiste en combinar el conjunto de
módulos ya probados (Al principio será un conjunto vacío) con los siguientes
módulos a probar. Luego se va incrementando progresivamente el número de
módulos unidos hasta que se forma el sistema Completo. En la integración no
incremental o Big Bang se combinan todos los módulos de una vez. (Suárez P,
Fontela C, 2003:10).
2.1.2.1 Integración Incremental Ascendente.
Su proceso consiste en integrar primero los módulos de más bajo nivel. Este
proceso deberá seguir los siguientes pasos.
• Elegir los módulos de bajo nivel que se van a probar.

• Escribir un módulo impulsor para la entrada de datos de prueba a los
módulos y para la visualización de los resultados.
• Probar la integración de los módulos.
• Eliminar los módulos impulsores y juntar los módulos ya probados con los
módulos de niveles superiores, para continuar con las pruebas. (Suárez P,
Fontela C, 2003:10).
6
Ventajas de la Integración Incremental Ascendente:
• Las entradas para las pruebas son más fáciles de crear ya que los módulos
inferiores suelen tener funciones más específicas.
• Es más fácil la observación de los resultados de las pruebas puesto que es
en los módulos inferiores donde se elaboran se resuelven primero los
errores de los módulos inferiores que son los que acostumbran tener el
procesamiento más complejo, para luego nutrir de datos al resto del
sistema. (Suárez P, Fontela C, 2003:11).
Desventajas de la Integración Incremental Ascendente:
• Se requieren módulos impulsores, que deben escribirse especialmente y

que no son necesariamente sencillos de codificar.
• El sistema como entidad no existe hasta que se agrega el último módulo.
(Suárez P, Fontela C, 2003:12)
2.1.2.4 Integración Incremental Descendente.
Este proceso parte del módulo de control principal. Este módulo es el de mayor
nivel y los va incorporando con aquellos módulos subordinados gradualmente.
No hay un procedimiento considerado óptimo para seleccionar el siguiente módulo

a incorporar. La única regla es que el módulo incorporado tenga todos los módulos
que lo invocan previamente probados.
No existe una secuencia para seleccionar de manera óptima la integración, en la

mayoría de los casos debe buscarse el problema concreto y de acuerdo a este
buscar el orden de integración más adecuado para la organización de las pruebas
aunque existen unas pautas para establecer prioridades en los módulos:
7
Si hay secciones críticas en un módulo complicado, se debe proyectar la
secuencia de integración para incorporarlas lo antes posible, el orden de
integración debe incorporar cuanto antes los módulos de entrada y salida.
Existen principalmente dos métodos para la incorporación de módulos:

• Primero en profundidad: Se mueve verticalmente en la estructura de
módulos.
• Primero en anchura: Se mueve horizontalmente en la estructura de
módulos. (Suárez P, Fontela C, 2003:12).
Etapas de la Integración Descendente:
• El módulo de mayor nivel hace de impulsor y se escriben módulos ficticios

simulando a los subordinados, que serán llamados por el módulo de control
superior.
• Probar cada vez que se incorpora un módulo nuevo al conjunto ya
engarzado.
• Al terminar cada prueba, sustituir un módulo ficticio subordinado por el real
que reemplazaba, según el orden elegido.
• Escribir los módulos ficticios subordinados que se necesiten para la prueba
del nuevo módulo incorporado. ((Suárez P, Fontela C, 2003:11)
Ventajas de la Integración Descendente:
• Las fallas que pudieran existir en los módulos superiores se detectan en

una etapa temprana.
• Permite ver la estructura del sistema desde un principio, facilitando la
elaboración de demostraciones de su funcionamiento.
8
• Concuerda con la necesidad de definir primero las interfaces de los distintos
subsistemas para después seguir con las funciones específicas de cada
uno por separado. (Suárez P, Fontela C, 2003:12).
Desventajas de la Integración Descendente:
• Requiere mucho trabajo de desarrollo adicional ya que se deben escribir un

gran número de módulos ficticios subordinados que no siempre son fáciles
de realizar. suelen ser más complicados de lo que aparentan.
• Antes de incorporar los módulos de entrada y salida resulta difícil introducir
los casos de prueba y obtener los resultados.
• Los juegos de datos de prueba pueden resultar difíciles o imposibles de
generar puesto que generalmente son los módulos de nivel inferior los que
proporcionan los detalles.
• Induce a diferir la terminación de la prueba de ciertos módulos. (Suárez P,
Fontela C, 2003:12)
Los autores (Suárez P, Fontela C, 2003:13) definen otro tipo de pruebas.
2.1.3 Pruebas de Sistema.
Las pruebas de sistema se realizan una vez integrados todos los componentes. Su
objetivo es ver la respuesta del sistema en su conjunto frente a distintas
situaciones. Se simulan varias alternativas que podrían darse con el sistema
implantado y en base a ellas se prueba la eficacia y eficiencia de la respuesta que
se obtiene. Se pueden distinguir varios tipos de prueba distintos, por ejemplo:
• Pruebas Negativas: se trata de que el sistema falle para ver sus

debilidades.
9
• Pruebas de Recuperación: se simulan fallas de software y/o hardware
para verificar la eficacia del proceso de recuperación.
• Pruebas de Rendimiento: tiene como objeto evaluar el rendimiento del
sistema integrado en condiciones de uso habitual.
• Pruebas de Resistencia o de Estrés: comprueban el comportamiento del
sistema ante situaciones donde se demanden cantidades extremas de
recursos (número de transacciones simultáneas anormal, excesivo uso de
las memorias, etc.).
• Pruebas de Seguridad: se utilizan para testear el esquema de seguridad
intentando vulnerar los métodos utilizados para el control de accesos no
autorizados al sistema.
• Pruebas de Instalación: verifican que el sistema puede ser instalado
satisfactoriamente en el equipo del cliente, incluyendo todas las plataformas
y configuraciones de hardware necesarias.
• Pruebas de Compatibilidad: se prueba al sistema en las diferentes
configuraciones de hardware o de red y de plataformas de software que
debe soportar. (Suárez P, Fontela C, 2003:13).
2.2 Pruebas de Aceptación.
Las pruebas de aceptación buscan comparar el comportamiento del sistema con

los requisitos del cliente. El cliente ejecuta una serie de tareas típicas para
comprobar que se satisfacen sus requisitos, esta actividad puede o no incluir a los
desarrolladores del sistema.
Una prueba de aceptación describe un escenario, desarrolla una seria de pasos

donde se ejecutan desde la perspectiva del cliente. Este tipo de pruebas puede
estar asociado a requisitos funcionales o no funcionales. Aunque hay que tener en
cuenta que un requisito tiene una o más pruebas de aceptación asociadas. Las
10
pruebas de aceptación cubren desde escenarios típicos, frecuentes, hasta los más
excepcionales, (Suárez P, Fontela C, 2003:13).
2.2.1 Ventajas de las Pruebas de Aceptación.
Las pruebas de aceptación pueden utilizarse para:

• Obligar a definir requisitos que sean verificables.
• Valorar adecuadamente el esfuerzo asociado a la incorporación de un
requisito.
• Negociar con el cliente el alcance del sistema.
• Planificar el desarrollo interactivo e incremental del sistema.
• Guiar a los desarrolladores.
• Identificar oportunidades de reutilización.
Los requisitos para las pruebas de aceptación son especificados de muchas
maneras tales como:
• Textualmente
• UMl (diagramas de casos de uso)
• Plantillas o fichas
• Interfaces de usuario (bocetos)
• Elaborar confinaciones de las anteriores
(Suárez P, Fontela C, 2003:14)
La guía de Ingeniería de Software (SWEBOK) propone las siguientes pruebas.
2.2.2 Pruebas de Instalación.
Este nivel de las pruebas permite que el software se pueda comprobar en un

entorno final. Estas pruebas se utilizan para comprobar la configuración del
hardware y verificar los procesos de instalación.
11
2.2.3 Pruebas de Regresión.
Este tipo de pruebas se ejecutan de forma selectiva y repetidamente en un

componente para verificar que los cambios no han producido efectos indeseados
(es demostrar que cierto software que previamente pasó un conjunto de pruebas,
aun las pasa). Las pruebas de regresión son cualquier repetición de pruebas que
demuestra que el software no ha cambiado en nada excepto en aquellos aspectos
que se haya requerido así.
2.2.4 Pruebas de Rendimiento.
Estas pruebas tienen el objetivo de verificar que el software alcanza los

requerimientos de rendimiento especificados, particularmente los de capacidad y
tiempo de respuesta. Un tipo particular de pruebas de rendimiento son las
pruebas de volumen en los que las limitaciones internas del programa o sistema
se ponen a prueba.
2.2.5 Pruebas de Desgaste.
Estas pruebas ejecutan el software a su máxima capacidad para la que fue

diseñado.
2.2.6 Pruebas de Continuidad.
Un grupo de pruebas se ejecutan en dos versiones diferentes y después se

comparan los resultados.
12
2.2.7 Pruebas de Recuperación.
La finalidad de estas pruebas es verificar la capacidad del software para

reiniciarse después de un desastre.
2.2.8 Pruebas de Facilidad de Uso.
Este proceso evalúa lo fácil que resulta ser aprender a utilizar el software al
usuario incluyendo la documentación del software, la efectividad de las funciones
del software y finalmente recuperarse de errores ubicados por el usuario.
A continuación la guía de ingeniería de software (SWEBOK) recomienda una serie

de técnicas de pruebas.
2.3 Técnicas de Prueba según guía de Ingeniería de

Software Swebok.
El objetivo de todas las técnicas de prueba es revelar el mayor número de fallos

potenciales posible intentando romper el programa ejecutando una o más pruebas
seleccionadas.
2.3.1 Pruebas Basadas en la Intuición y la Experiencia del

Ingeniero de Software.
2.3.1.1 Pruebas Ad Hoc.
Una prueba ad hoc se toma como un caso exploratorio a menos que destape un
defecto. Las pruebas se generan a partir de la habilidad, intuición y experiencia en
programas similares del ingeniero de software. Las pruebas ad hoc pueden ser
13
útiles para identificar casos de prueba especiales, aquellos que no se pueden
extraer fácilmente mediante técnicas formales.
Las pruebas ad hoc se inician paralelamente al iniciar el programa, esta se hace

para tener una mayor comprensión del programa. Los datos obtenidos ayudan a
establecer prioridades sobre los módulos. Las pruebas ad hoc se utilizan para
examinar defectos muy rigurosos.
2.3.1.2 Pruebas por Exploración.
Las pruebas por exploración se definen como aprendizaje, diseño de pruebas y

ejecución de pruebas al mismo tiempo. Esto significa que las pruebas no se
definen primero como parte de un plan de pruebas establecido, si no que se
diseñan, ejecutan y se modifican dinámicamente. La efectividad de las pruebas
por exploración se basa en el conocimiento del ingeniero de software, que se
puede derivar de varias fuentes: el comportamiento observado del producto
durante las pruebas, su familiaridad con la aplicación, la plataforma o el proceso
de fallos, los posibles tipos de errores y fallos, el riesgo asociado con un producto
en particular, etc.
2.3.2 Técnicas Basadas en el Código.
2.3.2.1 Criterios Basados en el Flujo de Datos.
Las pruebas basadas en el flujo de datos tienen anotaciones con información

acerca de cómo las variables de programa se definen, se usan y se destruyen.
El criterio más efectivo es que todos los caminos de uso, requiere que para cada
variable se ejecute cada uno de los segmentos del camino del flujo de control de
esa variable, para el uso de una definición que se ejecuta con el fin de reducir el
14
número de caminos necesarios, se emplean estrategias menos efectivas como
todas las definiciones y todos los usos.
2.3.2.2 Modelos de Referencia para Pruebas Basadas en el Código.
Aunque no es una técnica en sí misma, la estructura de control de un programa se

representa usando gráficos de flujo en las técnicas de prueba basadas en código.
Un grafico de flujo es un grafico dirigido cuyos nodos y arcos se corresponden
con elementos del programa. Por ejemplo, los nodos podrían representar líneas de
código ininterrumpidas y los arcos la trasferencia de control entre nodos.
2.3.3 Técnicas Basadas en Errores.
Con diferentes niveles de formalización, las técnicas basadas en errores idean

casos de prueba que están específicamente orientados a descubrir categorías de
errores probables o predefinidos.
2.3.3.1 Conjeturar Errores.
En la conjetura de errores los casos de prueba se han diseñado específicamente

por ingenieros de software intentando imaginar los errores más probables en un
programa determinado. La historia de errores descubiertos en proyectos anteriores
es una buena fuente de información como lo es la experiencia del ingeniero.
2.3.3.2 Pruebas por Mutación.
Un mutante es una versión ligeramente modificada de un programa al que se le

está haciendo pruebas, diferenciándose tan solo de un pequeño cambio sintáctico.
Cada caso de prueba se aplica al original y a los mutantes generados: si una
prueba consigue identificar la diferencia entre el programa y el mutante se dice
15
que el mutante está muerto. Esta técnica se concibió originalmente para evaluar
un conjunto de pruebas.
Las pruebas por mutación, son un criterio de pruebas en sí mismas: o se generan

pruebas aleatorias hasta que se han matado a los mutantes, o se diseñan
pruebas específicas para matar a los mutantes supervivientes.
En el último caso, las pruebas por mutación se pueden clasificar como técnicas
basadas en código.
2.3.4 Técnicas Basadas en el Uso.
2.3.4.1 Perfil Operativo.
Durante las pruebas para la evaluación de la confiabilidad, el entorno debe

reproducir un entorno operativo tan fielmente como sea posible. La idea es deducir
la futura confiabilidad del software durante su uso real desde los resultados de las
pruebas. Para conseguir esto, se le asigna una probabilidad de distribución, o
perfil, a las entradas de datos, basándose en la frecuencia en que suceden
durante el funcionamiento real.
Frecuentemente como pruebas funcionales vs estructurales. Estos dos métodos

de selección de pruebas no se deben ver como alternativos si no como
complementarios de hecho, usan fuentes de información diferentes y se han
comprobado que remarcan diferentes tipos de problemas. Estas técnicas se
pueden combinar dependiendo del presupuesto para pruebas.
16
2.3.4.2 Deterministas vs Aleatorias.
Los casos de pruebas se pueden seleccionar de una forma determinista, de

acuerdo con una de las varias técnicas enunciadas, o seleccionadas
aleatoriamente de una distribución de entradas de datos, como se hace
normalmente en las pruebas de confiabilidad. Existen varias comparaciones
analíticas y empíricas que analizan las condiciones en que uno de los métodos es
más efectivo que el otro.
El SWEBOK muestra una sección importante para el proceso de las pruebas que
son las medidas de las pruebas.
2.4 Medidas de las Pruebas.
Algunas veces, las técnicas de pruebas se confunden con los objetivos de las
pruebas. Las técnicas de pruebas se deben ver como medios que ayudan a
conseguir los objetivos de las pruebas. Por ejemplo, la cobertura de condiciones
es una técnica de pruebas más popular. Conseguir el valor de la cobertura de
condiciones no debería ser un objetivo de las pruebas en sí mismo: es solo un
medio para mejorar las posibilidades de encontrar fallos realizando pruebas
sistemáticas en cada condición del programa para un punto de decisiones. Para
prevenir dichas interpretaciones erróneas, debería hacerse una distinción muy
clara entre las medidas de las pruebas, que proporcionan una evaluación del
programa que se está comprobando, basada en los resultados observados de las
pruebas y aquellas que evalúan la completitud del conjunto de pruebas.
Las medidas se consideran, normalmente, como esenciales en los análisis de

calidad. Las medidas también se pueden utilizar para optimizar la planificación y
ejecución de las pruebas. La gestión de pruebas puede utilizar varios procesos
para medir o vigilar el progreso realizado.
17
2.4.1 Evaluación de un Programa durante las Pruebas.
2.4.1.2 Medidas para ayudar en la Planificación y Diseño de Pruebas de

Programas.
Las medidas basadas en el tamaño de un programa (por ejemplo, número de

líneas de código o métodos) o en la estructura de un programa (como la
complejidad), se usan para guiar a las pruebas. Las medidas estructurales
pueden incluir medidas entre módulos del programa, en términos de la frecuencia
en que cada módulo llama a los otros.
2.4.1.4 Densidad de Fallos.
Un programa que se está comprobando se puede valorar contando y clasificando

los errores descubiertos por su tipo. Para cada tipo de error, la densidad de
errores se mide como la razón entre el número de errores encontrados y el
tamaño del programa.
2.4.1.5 Vida de las Pruebas, Evaluación de Confiabilidad.
Una estimación estadística de la confiabilidad del software, es que se puede

conseguir mediante la realización y evaluación de la confiabilidad, se puede usar
para evaluar un producto y decidir si las pruebas se pueden detener o no.
2.4.1.6 Modelos de Crecimiento de la Confiabilidad.
Los modelos de crecimiento de la confiabilidad proporcionan una predicción de

confiabilidad basada en los fallos observados durante la realización y evaluación
de la confiabilidad. Estos modelos asumen, en general, que los errores que
18
causan los fallos observados se han arreglado (aunque algunos modelos también
aceptan arreglos imperfectos), y por tanto, el producto muestra una Confiabilidad
incremental de promedio. Existen docenas de modelos publicados en la
actualidad. Muchos se basan en algunas presunciones comunes, y otros no.
Mayoritariamente, estos modelos se dividen en modelos de cuenta de fallos y
tiempo entre fallos.
Es necesario realizar un análisis sobre las pruebas evaluadas. El Swebok, habla

sobre cuales son algunos tipos de prueba más utilizados.
2.5 Evaluación de las Pruebas Realizadas.
2.5.1 Cobertura Minuciosa de Medidas.
Varios criterios de suficiencia de prueba requieren que los casos de prueba

ejecuten sistemáticamente un conjunto de elementos identificados en el programa
o en la especificación. Para evaluar la minuciosidad de las pruebas realizadas los
ingenieros de pruebas pueden monitorear los elementos cubiertos y su número
total. La suficiencia de los criterios basados en código necesita la instrumentación
adecuada del programa que se está comprobando.
2.5.2 Introducción de Errores.
Algunas veces se introducen errores artificialmente en un programa antes de

comprobarlo. Cuando las pruebas se realizan, algunos de estos errores
aparecerán y posiblemente algunos otros que ya estaban en el software también
aparecerán.
19
En teoría, el número de los errores artificiales aparezca y cuántos de ellos se
puede evaluar. La efectividad de las pruebas se puede estimar por medio del
número restante de errores genuinos. En la práctica, los matemáticos
estadísticos se cuestionan la distribución y representatividad de los errores
introducidos en relación con los errores genuinos y el tamaño pequeño de la
muestra en la que se basa cualquier extrapolación. Algunos incluso afirman que
esta técnica debería usarse con sumo cuidado, ya que introducir errores en el
software acarrea el riesgo obvio de olvidarlos allí.
2.5.3 Puntuación de la Mutación.
En las pruebas por mutación, la razón de mutantes destruidos por número total de
mutantes generados puede ser una medida de la efectividad del conjunto de
pruebas realizadas.
2.5.4 Comparación y Efectividad Relativa de las Diferentes

Técnicas.
Se han llevado a cabo varios estudios para comparar la efectividad relativa de las
diferentes técnicas de pruebas.
Es importante ser preciso acerca de la propiedad contra la cual las técnicas se

han calificado; ¿cual, por ejemplo, es el significado exacto dado al término
“efectividad”? Las interpretaciones posibles son: el número de pruebas
necesarias para encontrar el primer fallo, la razón entre el número de errores
encontrados durante las pruebas y todos los errores encontrados durante y
después de las pruebas, o cual fue la mejora de la confiabilidad. Se han llevado a
cabo comparaciones analíticas y empíricas entre las diferentes técnicas, de
acuerdo con cada uno de los significados de efectividad especificados antes.
20
A continuación el Swebok revela la guía de cómo elaborar un proceso sobre
pruebas de software.
2.6 El Proceso de las Pruebas.
Los conceptos de pruebas, estrategias, técnicas y medidas han de ser integrados

en un proceso definido y controlado, que debe ser gestionado por personas. El
proceso de las pruebas soporta actividades y sirve de guía a los equipos de
pruebas, desde la planificación de las pruebas hasta la evaluación de los
resultados de las pruebas, de tal manera que se puede proporcionar una garantía
justificada de que los objetivos de las pruebas se conseguirán de una manera
económica.
2.6.1 Actitudes y Programación.
Un elemento muy importante para el éxito de las pruebas es una actitud de

colaboración respecto a las actividades de pruebas y garantía de calidad. Los
jefes de proyecto tienen un papel fundamental en fomentar una recepción
favorable en general respecto al descubrimiento de fallos durante el desarrollo y
mantenimiento; particularmente, previniendo que los programadores se
obsesionen con quien es el dueño del código, de tal forma que ninguno se sienta
responsable por los fallos que aparezcan en su código.
2.6.2 Guías para las Pruebas.
Se pueden guiar las fases de pruebas con varios mecanismos, por ejemplo; en
pruebas basadas en el riego, que usa los riesgos en el producto para asignar
prioridad y centrar la atención de las estrategias de pruebas; o en las pruebas
21
basadas en situaciones, en las que los casos de pruebas se definen y basan en
escenarios de software especificados.
2.6.3 Gestión del Proceso de las Pruebas.
Las actividades de pruebas realizadas a diferentes niveles se deben organizar,

junto con las personas, herramientas, normas y medidas, en un proceso bien
definido que será una parte integral del ciclo de vida del software Las pruebas no
se describen como un proceso independiente, si no que los principios de las
actividades de las pruebas se encuentran incluidos con los cinco procesos
primarios del ciclo de vida y con los procesos de soporte. Las pruebas se agrupan
con otras actividades de evaluación como una parte integral del ciclo de vida
completo.
2.6.4 Documentación y Productos de las Pruebas.
La documentación de pruebas puede incluir, entre otros, el Plan de Pruebas, la

Especificación del Diseño de las Pruebas, la Especificación del Procedimiento de
las Pruebas, la Especificación de los Casos de Pruebas, el Diario de las Pruebas
y el Informe de Problemas o de Incidentes durante las Pruebas. El software que
se está comprobando se documenta como el Artículo en Pruebas. La
documentación de las pruebas se debe generar y actualizar continuamente, con el
mismo nivel de calidad que cualquier otro tipo de documentación en la ingeniería
del software.
2.6.5 Equipo de Pruebas Interno vs Equipo Independiente.
La formalización del proceso de pruebas también puede formalizar la

organización del equipo de pruebas. El equipo de pruebas puede estar
22
compuesto por miembros internos (parte del equipo del proyecto, involucrados o
no en la construcción del software), o de miembros externos, con la esperanza de
contar con una perspectiva independiente y sin prejuicios, o, finalmente, de
miembros internos y externos. La decisión puede ser afectada por
consideraciones como coste, planificación, nivel de madurez de las organización
involucradas y como de crítica sea la aplicación.
2.6.6 Estimación Coste/esfuerzo y Otras Medidas del Proceso.
Los jefes de proyectos pueden usar varias medidas, acerca de los recursos
invertidos en las pruebas y de la efectividad de varias fases de pruebas en
encontrar fallos, para controlar y mejorar el proceso de las pruebas. Estas
medidas de las pruebas pueden cubrir, entre otros, aspectos como el número de
casos de pruebas especificados, el número de casos de pruebas ejecutados, el
número de casos de pruebas superados y el número de casos de pruebas no
superados.
La evaluación de los informes de las fases de pruebas se puede combinar con

análisis de las raíces de las causas para evaluar la efectividad del proceso de las
pruebas en encontrar errores tan pronto como sea posible. Dicha evaluación se
puede asociar con el análisis de riesgos. Lo que es más, los recursos que
merece la pena invertir en las pruebas deberían ser proporcionales al
uso/importancia de la aplicación: Diferentes técnicas tienen distinto coste y
proporcionan diferentes niveles de seguridad en la confiabilidad del producto.
2.6.7 Finalización.
Se debe tomar una decisión acerca de cuantas pruebas son suficientes y cuando
la fase de pruebas se puede finalizar. Las medidas concienzudas, como las
conseguidas mediante cobertura de código o completitud funcional y la estimación
23
de densidad de errores o de confiabilidad operativa, proporcionan un suporte
muy útil, pero no son suficientes por sí mismas. Esta decisión también incluye
consideraciones acerca del coste y los riesgos en que se incurrirá debido a los
fallos potenciales que aún queden, en vez del coste que conllevaría continuar
realizando pruebas.
2.6.8 Reutilización de pruebas y Patrones de Pruebas.
Con el objetivo de realizar pruebas o mantenimiento de una forma organizada y

efectiva respecto al costo, los medios usados para realizar pruebas en cada parte
del software se deberían reutilizar de una forma sistemática. Dicho repositorio de
material de pruebas debe estar bajo el control de un software de gestión de
configuraciones, de forma que los cambios en los requerimientos del software o el
diseño queden reflejados en cambios en el alcance de las pruebas realizadas.
Las soluciones adoptadas para realizar pruebas en determinados tipos de

aplicaciones bajo determinadas circunstancias, teniendo en cuenta los motivos
detrás de las decisiones que se han tomado, forman un patrón de pruebas que
se puede documentar y ser reutilizado en proyectos similares.
Para realizar pruebas es necesario construir actividades, las cuales ayudan a

gestionar el proceso de pruebas de software. La guía Swebok da a conocer
algunas de las actividades más utilizadas.
2.7 Actividades de las Pruebas.
En este punto, se verá una pequeña introducción a las actividades del software;
gestionar con éxito las actividades relacionadas con las pruebas, depende en gran
medida del proceso de Gestión de Configuración del Software.
24
2.7.1 Planificación.
Como cualquier otro aspecto de la gestión de proyectos, las actividades de las

pruebas se deben planificar. Algunos aspectos clave de las pruebas incluyendo la
coordinación de personal, la gestión de instalaciones y equipos disponibles (que
pueden incluir soportes magnéticos, planes de pruebas y procedimientos) y
planificar en caso de posibles situaciones no deseables. Si se mantiene más de
una línea base del software al mismo tiempo.
Una importante consideración de planificación es el tiempo y esfuerzo necesario

para asegurarse de que se ha usado la configuración correcta para establecer el
entorno de pruebas.
2.7.2 Generación de Casos de Pruebas.
La generación de caos de pruebas se basa en el nivel de pruebas que se vaya a

realizar y en las técnicas de pruebas a usar. Los casos de pruebas deberían estar
bajo el control de un software de gestión de configuraciones e incluir los resultados
esperados para cada prueba.
2.7.3 Desarrollo en el Entorno de Pruebas.
El entorno usado para las pruebas debería ser compatible con las herramientas
de ingeniería de software. Debería facilitar el desarrollo y control de casos de
pruebas y la anotación y recuperación de los resultados esperados, los scripts y
otros materiales de pruebas.
25
2.7.4 Ejecución.
La ejecución de las pruebas deberían incluir un principio básico de

experimentación científica, todos los pasos durante las pruebas se deberían
realizar y documentar de una forma lo suficientemente clara, que cualquier otra
persona debería ser capaz de reproducir los resultados. Por tanto, las pruebas
deben realizarse de acuerdo con los procedimientos documentados y usando una
versión claramente definida del software que se está comprobando.
2.7.5 Evaluación de los Resultados de las Pruebas.
Los resultados de las pruebas se deben evaluar para determinar si las pruebas
han sido satisfactorias o no. En la mayoría de los casos, “satisfactorias” significa
que el software se ha ejecutado como se esperaba y no ha tenido ningún
resultado inesperado importante. No todos los resultados inesperados son
necesariamente errores, ya que se podría considerar que algunos son un simple
ruido. Antes de que se pueda arreglar un error, se necesita realizar un análisis y
algún trabajo de depuración para identificarlo, aislarlo y describirlo. Cuando los
resultados de las pruebas son particularmente importantes, puede que se
convoque una revisión formal para evaluarlas.
2.7.6 Notificación de Problemas/Diario de Pruebas.
Las actividades de las pruebas se pueden añadir a un diario de pruebas para

identificar cuando una prueba se ha ejecutado, quien la ha realizado, que
configuración del software se ha utilizado y cualquier otra información relevante
de identificación. Resultados inesperados o incorrectos se pueden añadir a un
sistema de notificación de problemas, cuyos datos serán la base para procesos
de depuración posteriormente y para arreglar los errores que causaron
26
problemas durante las pruebas. Las anomalías no clasificadas como errores
también se podrían documentar, en caso de que más tarde resulte que producen
problemas más serios de lo que se pensó originalmente. Los informes de pruebas
también son una entrada para los procesos de requerimientos de cambió de
gestión.
2.7.7 Seguimiento de Defectos.
Los fallos observados durante las pruebas son, en la mayoría de los casos,
debidos a errores o defectos en el software. Dichos defectos se pueden analizar
para determinar cuando fueron introducidos en el software, que clase de error
produjo que se aparecieran (por ejemplo requerimientos definidos pobremente,
declaraciones incorrectas de variables, fallo de memoria o errores de
programación) y cuando deberían haber sido observados en el software por
primera vez. La información del seguimiento de defectos se usa para determinar
qué aspectos de la ingeniería del software necesitan mejorase y la efectividad de
análisis y pruebas anteriores.
La guía Swebok revela los aspectos más importantes para el proceso de

software.
2.8 Aspectos de las Pruebas.
Las actividades de las pruebas incluyen cuatro aspectos fundamentales las

cuales incluyen:
• Inspección de componentes, que encuentra defectos en componentes

individuales, la inspección de su código fuente.
27
• Pruebas unitarias, que encuentran defectos aislando un componente
individual usando manejadores de pruebas y ejercitando el componente
mediante un caso de prueba.
• Pruebas de integración, que encuentran defectos integrando varios
componentes.
• Pruebas de sistema, que se enfocan en el sistema completo sus
requerimientos funcionales y no funcionales y su a ambiente de destino.
2.8.1 Inspección de Componentes.
Las inspecciones encuentran defectos en un componente revisando su código,

estas inspecciones se pueden desarrollar antes o después de las pruebas
unitarias, el primer proceso de inspección estructurado fue elaborado por el señor
Michael Fagan |Fagan en el año 1976.
La inspección la realiza en equipo de desarrolladores junto con el autor del

componente, uno o dos revisores que encuentran defectos en el componente y un
moderador que facilita este proceso, el método de Fagan consiste en cinco pasos.
• Panorama. El autor del componente presenta de forma breve el propósito y

el alcance del componente y los objetivos de la inspección.
• Preparación. Los revisores se familiarizan con la implementación del
componente.
• Reunión de inspección. un lector comenta sobre el código fuente del
componente y el equipo de inspección plantea problemas relacionados con
el componente, el moderador se encarga de mantener la reunión en el
tema.
• Reparación. El autor revisa el componente
28
• Seguimiento. El moderador revisa la calidad de la reparación y determinad
si es necesario volver a inspeccionar el componente.
Las inspecciones de Fagan se perciben, por lo general, por lo consumidoras de

tiempo debido a lo largo de la fase de preparación y la reunión de inspección. La
efectividad de una revisión también depende de la preparación de los revisores.
Davis Parnas y Weiss en el año de 1985 replantearon el modelo de Fagan, en vez

de ello se les pide a los revisores que encuentren fallas durante la fase de
preparación al final de la preparación cada revisor llena un cuestionario que
prueba su comprensión del componente.
Luego el autor de reúne de forma individual con cada revisor para recolectar la
retroalimentación sobre el componente.
29
CAPITULO 3
ANALISIS Y DEFINICION DE UN
PROCEDIMEINTO DE PRUEBAS PARA
MUNDOS VIRTUALES.
3.1 Planeación de las Pruebas.
Los desarrolladores pueden reducir el costo de las pruebas y el tiempo

transcurrido necesario para terminar su producto de software mediante una
planeación cuidadosa.
Existen dos elementos clave, el primero de ellos es comenzar pronto la selección

de los casos de prueba y hacer las pruebas en forma paralela, los desarrolladores
responsables de las pruebas pueden diseñar casos de prueba tan pronto son
estables los modelos que validan. Las pruebas funcionales pueden desarrollarse
cuando terminen los casos de prueba, Las pruebas unitarias pueden desarrollarse
cuando sean estables las interfaces.
El rápido desarrollo de las pruebas permite que se inicie la ejecución de las

pruebas tan pronto como sea posible en los componentes. Además tomando en
cuenta que las pruebas de desarrollo requieren un examen cuidadoso de los
modelos que están bajo validación los desarrolladores pueden encontrar defectos
incluso antes de que se construya el mundo virtual.
30
Aunque estas pruebas tempranas incluyen un problema de mantenimiento:
• Es necesario actualizar los casos de prueba cada vez que cambien los
modelos del sistema.
• El segundo elemento clave para el acortamiento del tiempo de pruebas es
realizar las actividades de prueba en forma paralela.
3.2 Documentación de las Pruebas.
Las actividades de las pruebas se documentan en cuatro tipos de documentos.

• Plan de Pruebas. El plan de pruebas se enfoca en los aspectos
administrativos de las pruebas, es decir que el pan de pruebas documenta
el alcance, enfoque, recursos y calendarización las actividades de las
pruebas, en este documento se identifican los requerimientos y componente
a probar.
• Especificación de los Casos de Prueba. cada prueba se documenta con
una especificación de casos de prueba este documento contiene las
entradas, manejadores y salidas esperadas de las pruebas. Este
documento contiene todas las tareas a realizar.
• Reporte de Incidentes de Prueba. Cada ejecución de cada prueba se
documenta en un reporte de incidentes de la prueba.
Se registran los resultados reales de las pruebas y las diferencias con
respecto a la salida esperada.
• Reporte de Resumen de Pruebas. Este documento lista todas las fallas
que se descubrieron durante las pruebas y que necesitan investigarse.
A partir del informe de resumen de pruebas, los desarrolladores analizan y
asignan prioridad a cada falla y planean los cambios al sistema y a los
modelos, estos cambios, a su vez, pueden activar nuevos casos de prueba
y nuevas ejecuciones de pruebas.
31
3.3 Asignación de Responsabilidades.
Las pruebas requieren que los desarrolladores encuentren defectos en los

componentes del mundo virtual, para esto es recomendable que la prueba la
ejecute un desarrollador que no esté involucrado en el componente o en el
proyecto ya que se puede tener más posibilidades de encontrar ambigüedades en
la especificación de componentes.
Los requerimientos de calidad rigurosos, un equipo aparte dedicado al control de

calidad es el único responsable de las pruebas. Al equipo de pruebas se le
proporciona los modelos del sistema, el código fuente y el sistema para desarrollar
y ejecutar los casos de pruebas.
Después los reportes de incidentes de las pruebas y los reportes de resumen de

pruebas se envían de vuelta a los equipos de subsistema para su análisis y
posible revisión del sistema. Luego el equipo de revisión vuelve a examinar el
sistema no solo para comprobar si se corrigieron las fallas originales sino
también para asegurarse que no se hayan insertado nuevos defectos en el
sistema.
3.4 Etapas en el Proceso de Pruebas en Mundos

Virtuales.
Antes de especificar las etapas del proceso de prueba es importante mencionar

que para comenzar a ejecutar las pruebas tanto diseñadores como
desarrolladores deben reunirse para elaborar con base a los requerimientos otros
requerimientos propios del mundo virtual ejemplo el usuario desea un mundo
virtual. para dar a conocer los fenómenos que se desarrollan en el espacio, para
esto los diseñadores y los desarrolladores se reúnen y así determinar los
32
escenarios del mundo, los objetos que van a estar en cada uno de los escenarios,
como puede el usuario final manipular el mundo virtual, cuáles pueden ser las
animaciones del mundo virtual definir la historia del mundo virtual etc.
3.4.1 Etapa uno: Diseñador de Objetos Gráficos.
Esta etapa abarca toda la parte de diseño de objetos gráficos en 3d como en 2d

según lo requiera el mundo virtual, la etapa manejara varios casos de pruebas, los
cuales estarán representados por medio de formularios, cada formulario, contiene
la información adecuada de acuerdo al caso de prueba, la única semejanza de
estos formularios es que todos deben anexar las vistas del objeto según lo
requiera el objeto como vista superior, vista inferior, vista lateral derecha, vista
frontal etc.
El procedimiento de pruebas se encuentra dividido en tres etapas:

• Etapa uno diseñador de objetos.
• Etapa dos desarrollador.
• Etapa tres usuarios de prueba
La etapa uno es ejecutada por los diseñadores de los diferentes objetos y
animaciones del mundo virtual.
La figura 3.1 muestra la etapa uno en la que los diseñadores de objetos deben
tener en cuenta cuatro casos de prueba básicos a la hora de evaluar los
diferentes diseños para los mundos virtuales.
Todo mundo virtual tiene como inicio una idea no muy clara de escenarios,
dinámica del mundo, la historia que se va a tratar en el mundo virtual etc.
33
Fig. 3.1 Etapa Uno Proceso de Pruebas
3.4.1.1 Validar Objetos Según Requerimientos.
El diseñador en este caso de prueba debe verificar que a cada objeto le

correspondan los requerimientos iníciales del mundo virtual, características del
objeto como por ejemplo la forma, color, tamaño, características especiales, tipo
de textura del objeto. El diseñador no debe salir del contexto del mundo virtual,
este contexto hace referencia a ambientación, iluminación entre otros.
El formulario de la figura 3.1 captura toda la información referente a este caso de

prueba.
Formulario 3.1 Validación de Pruebas Según Requerimientos
34
Este formulario contiene:
El nombre de caso de prueba. Quien ejecuta la prueba debe especificar qué caso
de prueba aplicó a este objeto.
• Diseñador. se escribe el nombre del diseñador que construyó el objeto.
• Objeto construido en. Este campo es utilizado para especificarla el
nombre del programa.
• El número de prueba. es para llevar un control de cuántas veces se ha
ejecutado esta prueba, vale la pena mencionar que todas las etapas deben
cumplir con el mismo número de pruebas.
• El color del objeto. Nos indica si este está texturizado o pintado de
acuerdo a los requerimientos.
• El nombre del archivo. Nos ayuda a verificar de manera rápida la
ejecución de la prueba, esto lo pide el formulario para evitar el estar
buscado el archivo que contenga el objeto.
• La persona que ejecuta la prueba. ya que puede ser una persona
diferente al diseñador (lo cual no es obligatorio).
• Las características especiales. Nos dan a entender que tan bueno es el
objeto.
• Observaciones y sugerencias. Nos ayudan a tomar decisiones con
respecto a algún cambio o mejoramiento del objeto diseñado.
3.4.1.2 Comprobar Poligonización.
Este es un caso de prueba muy importante en el proceso e pruebas, debido a que

el mayor de los defectos en un mundo virtual es colocar en los objetos una
cantidad muy grande de polígonos, provocando un tiempo demasiado lento en la
carga de estos objetos y aun más en el tiempo de ejecución del mundo virtual.
Otra consecuencia es lograr que el mundo virtual solo se ejecute en
computadores demasiado potentes.
35
El objetivo del caso de prueba es lograr eliminar la mayor cantidad de polígonos
de los diferentes objetos y poder alcanzar un objeto liviano pero que a su vez no
pierda su forma de acuerdo a los requerimientos. En la mayoría de los programas
para diseñar objetos y animaciones se especifican todas las características de los
diferentes objetos como el color, tamaño, cantidad de polígonos etc. casi que es
solo cuestión de experiencia del diseñador en el programa para lograr quitar los
polígonos del objeto.
Al igual que el formulario anterior el cual también captura caso de prueba, objeto
construido en, prueba número, diseñador, nombre del archivo, características
especiales, observaciones y sugerencias las caulas ya han sido explicados
anteriormente.
Formulario 3.2 Comprobar Poligonización.
La única información adicional que captura el Formulario 3.2 (comprobar

Poligonización) es:
La cantidad de polígonos. Que fueron removidos del objeto este número puede
encontrarse en alguna función del programa en el cual se está desarrollando el
objeto.
36
3.4.1.3 Validar Animación.
Al igual que el caso anterior el objetivo principal es reducir el número de huesos

como sea posible pero sin perder la realidad de la animación del objeto. En la
mayoría de los programas creados para hacer animaciones en 3D manejan el
concepto armadura y huesos los cuales son el eje fundamental para diseñar y
construir animaciones en los objetos.
Las animaciones están determinadas por líneas de tiempo, un objeto puede tener
varias animaciones a la vez, estas diferentes animaciones están divididas por
unos segmentos de tiempo llamados frames. Para la frecuencia del ojo humano
las animaciones comprenden entre 20 y 24 frames esto quiere decir que una
animación entre este rango de frames puede verse fluida y no entre cortada.
Lo nuevo del formulario 3.3 es:
El Número de Huesos. (Armadura de la animación).

• La Cantidad Total de Frames. El responsable de la prueba debe
manifestar el número total de frames que tiene el objeto animado.
• La Especificación de Animación y Número de Frames. La cual consiste
en describir de manera breve cual es la animación ya sea correr, caminar,
girar tronco, fragmentación de un florero etc. Además especificar cuantos
frames se utilizaron para cada animación también mencionar en número de
frame inicial y el número final del frame en cada animación.
37
Formulario 3.3 Validar Animación.
3.4.1.4 Verificar Exportación de Objeto.
Este caso de prueba es importante para los desarrolladores y para los grupos de
la tercera etapa, porque dependiendo de cuál fue la herramienta que se exporte el
objeto se pueden limitar los defectos del objeto.
Existen unas herramientas de diseño 3d que pueden exportar todas las

propiedades que la herramienta maneja pero existen otros que no, ejemplo
Blender no puede exportar la luz que el crea para formatos B3D mientras que
Giles es una herramienta que importa este archivo b3d y permite generar luz para
ese objeto y al exportarlo en formato b3d el objeto queda con la iluminación
creada en Giles.
El formulario 3.4 simplemente agrega.
38
• El formato de exportación. Que no es más sino el nombre de la extensión
en la que se exporto ejemplo (b3d, 3ds, x3d, obj etc.).
• Exportado en. Donde se debe manifestar de cual herramienta fue
exportado por última vez.
Formulario 3.4 Verificar Exportación De Objetivos.
3.4.1.5 Evaluación/Informes.
Es el cierre de la etapa uno, para este cierre se reúne a todo el equipo de la etapa
uno para hacer un último análisis de la ejecución de pruebas y generar un informe
adicionando las plantillas de pruebas, el reporte debe contener información sobre
el proyecto el cual se está desarrollando ubicación de toda la información en este
caso de donde se encuentran todos los objetos, la lista de los objetos probados.
En caso de un desacuerdo entre el grupo se realizará una revisión en esta etapa

por los integrantes del grupo.
39
3.4.2 Etapa Dos: Programador.
Fig. 3.2 Etapa Dos del Proceso de Pruebas
La figura 3.2 muestra la etapa dos, hace referencia a los desarrolladores quienes
son los que importan los objetos controlan las animaciones organizan y arman el
mundo virtual etc.
3.4.2.1 Importar Objetos.
Los desarrolladores deben verificar los objetos cuando se importan al mundo

virtual, esto se hace debido a que al cargarlos y hacer una visualización de objeto
puede ocasionar un colapso en sistema o en el mundo virtual. El formulario 3.5 en
nos permite plasmar las siguientes especificaciones.
40
• La Descripción del Problema. Si el desarrollador tiene algún problema al
importar el objeto debe especificarlo en esta sección.
• Observaciones y Sugerencias. opinar o proponer una solución al
problema.
Formulario 3.5 Importación de Objetos.
3.4.2.2 Tiempo de Ejecución.
Caso de prueba importante, porque este caso nos permite mejorar la rapidez del
mundo virtual, ejemplo la carga de submundos virtuales, las diferentes mallas,
imágenes, sprites etc.
Los desarrolladores deben observar la mejor manera para codificar el mundo

virtual y poder lograr que el producto 3d sea lo más liviano posible en modo
ejecución. El formulario 3.6 no ayuda a marcar la siguiente característica.
Observaciones y sugerencias consiste en quien ejecuta la prueba pueda

expresar los posibles defectos en el tiempo de ejecución ya sea una carga de
objetos de forma repetitiva o la manera de controlar una animación de un objeto,
41
también pude ser cuando se eliminan los objetos o como está dividido el mundo
virtual
Formulario 3.6 Tiempo de Ejecución
3.4.2.3 Ejecución, Animaciones de Objetos.
Las animaciones son creadas por los diseñadores pero ellos solo hacen un ciclo
de cada animación para un objeto.
La tarea del desarrollador con este tipo de objetos es ubicarlos en la escena y

controlar la animación de estos objetos generando las repeticiones de la
animación según sea el mundo virtual. La prueba consiste en examinar la realidad
de las animaciones es decir si al generar un bucle en las animaciones se denota
algún defecto en ellas. El desarrollador puede especificar en el formulario 3.7.
• Las características principales de la animación. Según su punto de vista
como desarrollador
• Agregar sugerencias. Para especificar sugerencias sobre la animación del
objeto.
• Falla en intervalo.es para el programador escriba el intervalo o los
intervalos en los que la animación presenta defectos. Por ejemplo, la
42
animación presenta fallas en los Frames 23,24 o intervalo de Frames 15
hasta el frame 19.
Formulario 3.7 Ejecución, Animación De Pruebas.
3.4.2.4 Tolerancia de Hardware.
Este caso de prueba tiene como objetivo limitar el mundo virtual para la ejecución
de las diferentes computadoras.
No todos los video juegos se ejecutan en cualquier computador existen algunos

que requieren tarjetas de video, memoria RAM, grandes cantidades de disco duro
y procesadores de alto rendimiento.
Para esto los desarrolladores deben probar el mundo en varias computadoras de

tal manera que se pongan de acuerdo para establecer los requerimientos mínimos
de hardware para el mundo. Para esto debe hacerse una reunión entre delegados
o jefes de grupo tanto diseñadores como los desarrolladores.
43
El formulario 3.8 adjunta información importante aparte de la información estándar
anteriormente explicada, el formulario 3.8 archiva información sobre las
características del hardware tales como.
• Memoria RAM. Se especifica el valor más pequeño que el juego puede

soportar.
• Tarjeta de Video es para determinar si el juego requiere de una tarjeta de
video.
• Memoria del Video. Quien ejecuta la prueba debe especificar el valor
mínimo de memoria de video que el juego requiere para su ejecución.
• El sistema operativo. Determinar Para cual sistema operativo el juego está
diseñado.
• Características de sistema operativo. Ejemplo Sistema operativo
(Windows XP).
• Especificaciones de SO. (Profesional SP2 o superior).
• Procesador se debe especificar el procesador más pequeño que pueda
soportar el video juego.
Formulario 3.8 Tolerancia de Hardware
44
3.4.2.5 Validación de Objetos Según Requerimientos, Validar Animación y
Comprobación de Polígonos.
En algunas ocasiones les es más factible desarrollar algunos objetos ellos

mismos, es mejor por muchas características, mejor movilidad en el editor del
mundo virtual, manejo de más propiedades sobre el objeto, se puede lograr
controlar mejor la animación etc.
Todas esas características y mas dependen del editor 3d que el desarrollador

emplea, hacen que la etapa dos maneje estos dos casos antes mencionados en la
etapa uno, pues el desarrollador debe en ese caso evaluar sus objetos,
animaciones o poligonización.
Para la validación de objetos se utilizan los mismos formularios que utiliza el

diseñador en estos casos de prueba al igual que validar animación y
comprobación de polígonos.
3.4.2.6 Evaluación/Informes.
Es el cierre de la etapa dos, para este cierre se reúne a todo el equipo de la etapa
dos y así poder hacer un último análisis de la ejecución de pruebas y generar un
informe adicionando las plantillas de pruebas, el informe debe contener
información sobre el proyecto el cual se está desarrollando como lo es la ubicación
de toda la información en este caso de donde se encuentran todos los
componentes del mundo virtual. Además se deben anexar las plantillas de los
componentes evaluados.
45
En caso de un desacuerdo entre el grupo se realizara una revisión en esta etapa
por los integrantes del grupo.
3.4.3 Etapa Tres Usuarios de Prueba.
Fig. 3.3 Etapa Tres del Proceso de Pruebas
La figura 3.3 muestra un bosquejo de la etapa tres es, una etapa de casos de
prueba para el usuario final en donde personas ajenas al proyecto elaboran
pruebas al mundo desde su instalación como maniobrabilidad, efectos visuales y
tolerancias a errores ajenos como no al mundo virtual.
Estas personas son llamadas en esta etapa usuarios de prueba porque son
personas ajenas al proyecto desarrollado pero pueden ser diseñadores o
desarrolladores de otros proyectos (otros mundos virtuales) que se encargan de
representar el papel de usuarios finales.
Una vez terminada de ejecutar esta etapa los integrantes del grupo de evaluación
de esta etapa se reúnen para elaborar un informe el cual contiene la información
de las plantillas y al final del informe las sugerencias sobre el mundo virtual en
ocasiones una sugerencia puede ser volver a ejecutar las pruebas desde el
46
comienzo pero esta vez se ejecuta basándose en la información y sugerencias de
las plantillas de todas las etapas.
Si el grupo no digiere otra ejecución entonces deben informar como terminado el

proceso de pruebas.
3.4.3.1 Instalación del Mundo Virtual.
Caso de prueba en el cual un grupo de la etapa tres instala el mundo virtual en un

computador que cumpla con los mínimos requerimientos de hardware como por
ejemplo memoria 256 RAM, disco duro de 40Gb, video 32Mb, el video no es 3d, el
procesador sea de 1ghz, etc. Tanto en un computador del alto rendimiento es
decir que el computador posea 2Gb RAM, disco duro 500Gb, video 512Mb, el
video es 3d, el procesador es 3.2Ghz, etc.
La prueba finaliza al ejecutar por primera vez el mundo virtual, el objetivo es lograr
que tanto en la máquina de requerimientos mínimos, como la máquina de alto
rendimiento no generen ningún tipo de fallas al iniciar por primera vez el mundo
virtual.
Quien ejecuta la prueba debe colocar en el formulario las características de la

máquina.
• Memoria RAM. Es la cantidad de memoria RAM mínima que necesita el
mundo virtual.
• Procesador. Quien ejecuta la prueba debe especificar la frecuencia mínima
que necesita el mundo virtual para su ejecución.
• Sistema. Operativo. Hay que especificar en qué sistema operativo se
instaló el mundo virtual.
47
• Especificación del SO. La persona responsable de la ejecución de la
prueba debe aclarar las características del sistema operativo como por
ejemplo Windows xp sp2 versión 2002 a 32bits.
• Espacio en disco duro. Es un campo para quien ejecuta la prueba
especifique cuanto espacio de disco duro ocupa el mundo virtual.
• Las especificaciones de la instalación son para aclarar alguna anomalía
en la instalación del juego, quien ejecuta la prueba debe llenar en el
formulario 3.9, para determinar si la instalación fue o no exitosa.
Formulario 3.9 Instalación del Mundo Virtual.
3.4.3.2 Maniobrabilidad.
El formulario 3.10 contiene la maniobrabilidad del mundo virtual, sirve para evaluar
que tan rápido se adapta el usuario al mundo, que tan fácil resulta para el usuario
controlar el mundo virtual, si en verdad se siente cómodo con los controles del
mundo virtual etc.
El usuario que ejecuta la prueba debe especificar:
48
• La calidad de la maniobrabilidad. Puede ser Mala, Buena, o excelente.
• Características Especiales. El usuario puede resaltar las características
buenas que tiene el mundo virtual correspondiente a la maniobrabilidad.
Ejemplo los movimientos de cámara son muy fluidos, el orden de los
controles es muy cómodo etc.
• Observaciones y sugerencias. quien desarrolla la prueba puede opinar de
algún aspecto que él considere que se puede mejorar o cambiar.
Formulario 3.10 Maniobrabilidad.
3.4.3.3 Efectos Especiales.
Cuando se evalúan los efectos especiales nos referimos a las imágenes que
brillan o que se fragmentan durante la ejecución del juego, la mayoría de los
efectos especiales son elaborados de forma matemática con tratamiento de
imágenes. Ejemplo la llama de una antorcha, el agua, chispas de un corto circuito,
el humo de un automóvil, la iluminación de un bombillo etc.
49
En el formulario 3.11 las personas encargadas de ejecutar esta prueba deben
observar detalladamente los efectos, es decir que sean acordes al mundo real,
que la textura sea lo bastante real etc.
Los efectos especiales en un mundo virtual hacen que el usuario no se distraiga

del mundo virtual.
Formulario 3.11 Efectos Especiales.
3.4.3.4 Tolerancia a Errores Externos.
Este caso de prueba evalúa que tan robusto es el mundo virtual a fallas o errores
ajenos a el producto 3d, como lo es por ejemplo que en el momento de guardar la
partida no haya energía, que el computador presente fallas de hardware, que haya
un colapso en el sistema operativo o que el equipo se apague de repente también
puede ser que el equipo se reinicie de forma inesperada.
50
El usuario que ejecuta la prueba debe colocar en el formulario 3.12 un informe de
la fallas que presenta el producto ante un reinicio inesperado, una falta de energía,
fallas en el hardware y agregar sugerencias y observaciones paras así aportar una
o varias soluciones al problema.
Formulario 3.12 Tolerancia A Errores Externos.
3.4.3.5 Evaluación / Informes.

Para la entrega de este informe se reúnen todo los integrantes del grupo y
determinar si es o no necesario realizar nuevamente las pruebas.
En conclusión el proceso completo para la ejecución de pruebas se ve

representado en la figura 3.5.
51
Fig. 3.5 Las Tres Etapas del Proceso de Pruebas.
52
CAPITULO 4
DEMOSTRACIÓN DE EJECUCIÓN DEL
PROCEDIMIENTO DE PRUEBAS A UN
MUNDO VIRTUAL LLAMADO
FISMAGIC.
FisMagic es un proyecto de física el cual contiene temas de electromagnetismo,

este proyecto es otra manera de experimentar, apreciar y aprender más sobre la
física en el campo del electromagnetismo.
Este proyecto está a cargo del profesor Ariel Becerra, PhD en física quien
coordinó toda la parte de física de este proyecto y fue elaborado por tres
ingenieros de sistemas y un diseñador gráfico.
Es importante resaltar que este proyecto tiene derechos de autor por lo que no es
posible mostrar código fuente del mundo virtual, sin embargo para este trabajo el
coordinador del proyecto facilitó el mundo virtual en su etapa de construcción es
decir no terminado aún.
FisMagic en su última versión tiene aproximadamente entre 12 y 14 temas de

electromagnetismo diseñados y desarrollados por módulos o componentes.
53
Recomendaciones importantes a la hora de crear Mundos Virtuales.
Diseño.
• Tener en cuenta el diseñar los objetos de la manera más liviana posible
pero sin perder la forma o el realismo del objeto.
• Hacer los escenarios por partes para poder así administrar mejor los
recursos de la maquina.
• Al texturizar optar por imágenes que no sean demasiado pesadas, si es
posible lograr texturizar los objetos con una sola imagen se lograría más
rendimiento.
Desarrollo.
• Evitar importar objetos o imágenes en ciclos de programación como for,
while, etc.
• Construir los mundos virtuales por módulos.
• Cuando un modulo finalice su ejecución es recomendable liberar objetos,
imágenes o mallas para administrar así de manera optima los recursos de
la maquina.
Usuario.
• Verificar siempre cómo se comporta el mundo virtual en el computador, es
decir que sea agradable, fácil de manipular, divertido, que se comporte de
manera fluida (rápida) etc.
El objetivo principal de este capítulo es la demostración de cómo aplicar el

procedimiento definido en el capítulo tres a un mundo virtual.
Debido a que el mundo virtual comprende demasiados escenarios se

seleccionarán aquellos que abarquen las características para la ejecución de
todos los casos de prueba.
54
4.1 Demostración Etapa Uno.
Fig. 4.1 Mundo Virtual FisMagic.
55
4.1.1 Validación Según Requerimientos.
Fig. 4.1.1 Giroscopio Objeto diseñado en Blender.
El objeto a evaluar se obtiene del primer modulo del mundo virtual.

Los requerimientos son:
• Crear un emblema representativo a la física y ubicarlo en la piscina.
• Que sea un objeto animado.
• Que sea llamativo y presentable.
Formulario 4.1 Demostración Primer Caso de Prueba Etapa Uno.
El estado de esta ejecución de prueba es Semiaprobado.
56
4.1.2 Comprobar Poligonización.
Formulario 4.2 Demostración Segundo Caso de Prueba Etapa Uno.
Esta prueba representa una Poligonización tolerable porque el objeto no

demuestra deformaciones esto sucede porque para este caso con respecto al
objeto no es recomendable eliminar polígonos ya que el objeto puede presentar
deformaciones más adelante.
4.1.3 Valida animación.
Fig. 4.1.2 Animación de Objeto en Blender.
57
Formulario 4.3 Demostración Tercer Caso de Prueba Etapa Uno.
El estado de esta prueba es aprobado, la animación es fluida, libre es decir que no

presente cortes entre los Frames.
4.1.4 Verificar Exportación de Objeto.
Formulario 4.4 Demostración Cuarto Caso de Prueba Etapa Uno.
58
4.1.5 Evaluación / Informes.
Proyecto evaluado FisMagic
Informe 01
Etapa 01
Fecha 03/05/07
Según las pruebas realizadas al objeto giroscopio2.blend ubicado en Equipo 3

dirección (d:\diseño blender\objetos3d\) se llega a la conclusión general d:
Continuar a la siguiente etapa_____, debe pasar a una nueva revisión_____
Se anexan ___ formulario(s) para constatar el resultado del informe.
4.2 Etapa Dos Desarrolladores.
Fig. 4.2 Componente Uno Mundo Virtual FisMagic.
59
4.2.1 Importación de Objetos.
En este caso el objeto que se importo fueron los tres cubos unidos que contienen
las esferas rojas y verdes.
Formulario 4.5 Demostración Primer Caso de Prueba Etapa Dos.

El estado de la ejecución de esta prueba es aprobado porque no hubo ningún
problema al importar el objeto.
4.2.3 Tiempo de Ejecución.
Para esta prueba se tendrá en cuenta como se mueve el objeto creado en blender
bajo otro entorno como lo es blitz
Formulario 4.6 Demostración Segundo Caso de Prueba Etapa Dos.
60
El estado de eta prueba es semiaprobado, pues las animaciones corresponden
pero hay que mejorarlas es sucede debido a muchas razones: No se utilizo la
ecuación adecuada al movimiento, otra animación puede estar bloqueando la
animación del objeto evaluado.
4.2.4 Ejecución, Animaciones de Objetos.
Para este caso de prueba se fijara en la animación del objeto importado pues
puede presentar cortes en la animación debido al entorno.
Formulario 4.7 Demostración Tercer Caso de Prueba Etapa Dos.
Estado de la prueba es aprobado úes no presenta ningún frame o intervalo de

Frame que genere defectos en el objeto.
61
4.2.5 Tolerancia de Hardware.
Formulario 4.8 Demostración Cuarto Caso de Prueba Etapa Dos.
Formulario 4.8.1 Demostración Quinto Caso de Prueba Etapa Dos.
El estado de esta prueba es semiaprobado pues tanto en los dos sistemas

operativos como en los dos computadores presentan las mismas fallas.
4.2.6 Validación de Objetos Según Requerimientos.
Este es un caso de prueba que puede repetirse en esta etapa ya que el

desarrollador puede crear objetos y animación desde su código fuente.
62
Para esta demostración solo se ejecutara una de los casos que se repiten pues la
ejecución es la misma lo único que cambia es que ya no es bajo la herramienta
blender si ahora es la herramienta blitz.
Formulario 4.9 Demostración Sexto Caso de Prueba Etapa Dos.
El estado de esta prueba es aprobado pues cumple con el requerimiento de la

ubicación del objeto.

Informe 01
Etapa 02
Fecha 03/09/07

63
4.3 Etapa Tres Usuario de Prueba.
Fig. 4.3 Menú Principal FisMagic.
4.3.1 Instalación del Mundo Virtual.
Formulario 4.10 Demostración Primer Caso de Prueba (a) Etapa Tres.
64
Formulario 4.10.1 Demostración Primer Caso de Prueba (b) Etapa Tres.
Estado de la ejecución de la prueba es aprobado porque se instalo el producto de

manera exitosa en los dos computadores con sus sistemas operativos respectivos
4.3.2 Maniobrabilidad.
Formulario 4.11 Demostración Segundo Caso de Prueba Etapa Tres.
Estado de la ejecución de prueba es semiaprobado pues la parte de

maniobrabilidad hay que discutirla con los requerimientos.
65
4.3.3 Efectos Visuales.
Formulario 4.12 Demostración Tercer Caso de prueba Etapa Tres.
Fig. 4.5 Vista Polígonos de mallas Componente Uno FisMagic.
La ejecución de esta prueba arroja como resultado de su estado no aprobado

debido a que hay animaciones con defectos muy visibles.
66
4.3.4 Tolerancia a Errores Externos.
Formulario 4.13 Demostración Cuarto Componente Etapa Tres.
Esta etapa arroja como resultado un estado aprobado pues es muy robusto a este
tipo de fallas.

Informe 01
Etapa 03
Fecha 03/11/07

Este proyecto debe volverse a evaluar debido a los errores, fallas y defectos que
posee.
67
A medida que suben los niveles de ejecución de pruebas las etapas son mucho
más estrictas en sus ejecuciones y así lograr evitar que suba el nivel de las
pruebas.
68
MARCO LEGAL.
Para el desarrollo de esta investigación se utilizaron recursos de software libre

como lo es Blender 2.47 el cual puede ser descargado de www.Blender.org y la
versión demos de blitz3d la cual puede encontrarse en www.blitz.org.
69
INFLUENCIA AMBIENTAL.
El desarrollo de esta investigación no presenta ninguna influencia ambiental, ya

que tanto como dispositivos, equipos y tecnologías que se utilizaron en el diseño
de pruebas para mundos virtuales no afectan ni perjudican en ningún momento el
medio ambiente y al ser humano; de lo cual se pudo hacer buen uso de los
mismos, sin dañar el medio que nos rodea.
70
CONCLUSIONES.
Al finalizar con el proyecto de grado se logró crear un procedimiento de pruebas

para los mundos y los objetos 3d, 2d que lo componen determinando así que:
• El proceso de pruebas es rápido y objetivo al momento de ejecutarse

.
• El proceso cubre los principales aspectos para lograr un buen producto
virtual.
• Este procedimiento logra unir y evaluar los puntos más importantes en la

creación de los mundos virtuales.
• Es una iniciativa hacia las personas que deseen comenzar a evaluar sus
productos y ayudar a mejorar este procedimiento.
71
RECOMENDACIONES.
• Debido a que la tecnología cambia a grandes pasos. Los videojuegos

crecen y son aun más exigentes es por esta razón que el procedimiento de
ejecución de pruebas debe también ir mejorando a medida que avanzan
los productos virtuales.
• Determinar la efectividad de este proceso de pruebas para el desarrollo de
mundos virtuales.
• Definir el proceso de aplicación de métricas en el proceso de evaluación.
72
GLOSARIO DE TÉRMINOS Y
SÍMBOLOS.
Colisión: Definición dada por el programador para determinar el límite entre dos o
más objetos.
Defecto: causa de un funcionamiento incorrecto.
Error: causa de un funcionamiento incorrecto.
Falla: efectos no deseados observados por un los servicios proporcionados por un

sistema.
Frame: fotograma de video o una imagen de animación creada por el computador
Hueso: estructura que se genera y se acopla al objeto para crear animaciones.

Giles: software de diseño de mundos virtuales ayuda a crear efectos como
iluminaciones
Iluminación: luz virtual añadida a escenarios y objetos 3d
Polígono: forma cerrada con tres o más caras
SWEBOK: guía elaborada sobre las aéreas del conocimiento sobre el desarrollo
de ingeniería de software.
Textura: imagen utilizada para cubrir un determinado objeto o parte de él.
73
BIBLIOGRAFÍA.
• Bruegge “Ingeniería de software orientada a objetos”
Colección: COLLEGE
Editorial: Pearson (2002, 0ª edición)
• Suarez P & Fontela C “Documentación y Pruebas Antes del Paradigma de

los Objetos” 2003.
Url: http://materias.fi.uba.ar/7507/content/7507_pruebas.pdf: facultad de
ingeniería Universidad Buenos Aires.
• http://www.swebok.org/pdfformat.html: página oficial que proporciona

documento original del Swebok 2004, esta guía fue diseñada en base a la
variedad de audiencias alrededor del mundo.
• http://www.leedor.com/notas/ver_nota.php?Idnota=92: breve reseña del
autor pablo Suarez
• http://www.librosenred.com/autores/carlosfontela.html: breve reseña del
autor Carlos Fontela
74
ANEXO I.
PRESUPUESTO GENERAL
Recursos Humanos $ 4.800.000
Recursos Físicos $ 4.950.000
Recursos Económicos $ 310.000
Total $ 10.060.000
Tabla 1 Presupuesto Económico.
Recursos Humanos.
La realización del trabajo de grado se llevó a cabo con la ayuda del director del
proyecto Ing. Edgar Albornoz.
Recursos Físicos.
Descripción Cantidad Valor Total
1. Computador AMD Sempron 2800+ GHZ, RAM 1 1.500.000 $ 1.500.000

1.5 GB Disco duro de250 GB y DVD-ROM.RW
2. Mesa para computador 5 $ 120.000 $ 600.000
3. Silla para computador 5 $ 50.000 $ 250.000
4. Impresora de Tinta 1 $ 100.000 $ 100.000
Total $ 2.450.000
Tabla 2 Recursos Físicos.
75
Recursos Económicos.
Descripción Cantidad Valor Total
Papelería General --- $ $ 45.000

45.000
Gastos Varios --- $ $ 55.000

55.000
Cartuchos para impresora 1 $ $ 90.000

90.000
Servicio de Internet mensual 4 $ $ 120.000

30.000
Total $ 310.000
Tabla 3 Recursos Económicos.
ANEXO 2
FUENTES DE FINANCIACIÓN.
Para la realización de este trabajo de Investigación los recursos económicos

fueron totalmente financiados por mis padres y los recursos humanos fueron:
proporcionados por el Director del proyecto el Ing. Edgar albornoz el profesor Ariel
Becerra PH en física.
76
ANEXO 3.
Plantillas para la ejecución de pruebas en mundos
virtuales.
77
78
79
80
81

Definición y Aplicación de Un Método para El Desarrollo de Mundos Virtuales en Entornos Web

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Definición y Aplicación de Un Método para El Desarrollo de Mundos Virtuales en Entornos Web

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD DE PAMPLONA

FACULTAD DE INGENIERIAS Y ARQUITECTURA

PROGRAMA DE INGENIERIA DE SISTEMAS

DEFINICIÓN DE UN PROCEDIMIENTO PARA LA APLICACIÓN DE PRUEBAS

AUTOR: ELLELVER ARLEYNDER MENESES JAIMES

PROGRAMA DE INGENIERIA DE SISTEMAS

TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

AUTOR: ELLELVER ARLEYNDER MENESES JAIMES

PROGRAMA DE INGENIERIA DE SISTEMAS

TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

DEFINICIÓN DE UN PROCEDIMIENTO PARA LA APLICACIÓN DE PRUEBAS

PROYECTO DE TRABAJO DE GRADO PARA OPTAR POR EL TÍTULO DE

DEFINICIÓN DE UN PROCEDIMIENTO PARA LA APLICACIÓN DE PRUEBAS EN EL

INICIO DEL TRABAJO DE GRADO: AGOSTO DE 2008

EL JURADO CALIFICADOR CONFORMADO POR: (Nombres, apellidos y documento de identidad).

JURADO 1: ________________________________________________/ C.C: _______________________________

JURADO 2: ________________________________________________/ C.C: _______________________________

JURADO 3 ________________________________________________ / C.C: _______________________________

JURADO 4*: _______________________________________________/ C.C: _______________________________

EN SU SESIÓN EFECTUADA EN: ______________________________________________________________ A LAS ___________

Primera Conclusión: Otorgar la Calificación de: ___.___ (Si aplica)

(PARA PREGRADO) EXCELENTE APROBADO INCOMPLETO

(*PARA POSTGRADO) APROBADO NO APROBADO

AL TRABAJO DE GRADO TITULADO:

AUTOR: ____________________________________________________ /C.C:_____________________

Segunda Conclusión: Emitir los siguientes criterios

Firmas del Jurado Calificador:

______________________ _________________________ ____________________ ___________________

Dedicado a todas aquellas personas que buscan el conocimiento, personas que

Este trabajo se da por la falta de un procedimiento de ejecución de pruebas para

Para definir este procedimiento de pruebas se desarrollo un estudio sobre la guía

Uno de los principales problemas es la ejecución de pruebas a los mundos

Este trabajo propone un procedimiento para la ejecución de pruebas en mundos

El procedimiento de prueba nos ayuda a corroborar si existen o no errores en la

Pero A medida que pasa el tiempo se adquiere más experiencia en la

Las técnicas de pruebas de software en el desarrollo de mundos virtuales.

1.3 Necesidades y Problemas.

El grupo de Investigación INTEGRAR de física de la universidad de pamplona, se

La necesidad de aplicar un método de prueba para los objetos y las simulaciones

1.4 Criterios de Viabilidad.

1.5.1 Objetivo General.

Definir un procedimiento para la ejecución de pruebas en el desarrollo de mundos

1.5.2 Objetivos Específicos.

• Estudiar y documentar diferentes técnicas de pruebas para el desarrollo de

• Plantear un procedimiento para la definición y ejecución de casos de

• Aplicar el procedimiento de prueba al un prototipo de mundo virtual

Ejecutar pruebas es una actividad muy importante en cualquier tipo de desarrollo

La guía de ingeniería Swebok define los siguientes niveles de prueba.

2.1 Niveles de Prueba.

Las pruebas se ejecutan en diferentes niveles de desarrollo de software,

Las pruebas de software se realizan normalmente a diferentes niveles durante los

Una manera de acoplar los niveles de prueba al procedimiento de pruebas para

2.1.1 Pruebas de Unidad.

Este tipo de prueba verifica y evalúa el funcionamiento aislado de partes de

2.1.2 Pruebas De Integración.

La base fundamental de las pruebas de integración son las pruebas unitarias, y

El orden de integración de los módulos influye en:

• La forma de preparar los casos de prueba.

Existen principalmente dos tipos de integración: La integración incremental y la no

2.1.2.1 Integración Incremental Ascendente.

• Elegir los módulos de bajo nivel que se van a probar.

Desventajas de la Integración Incremental Ascendente:

• Se requieren módulos impulsores, que deben escribirse especialmente y

JURADO 1: __________________/ C.C: _

JURADO 2: __________________/ C.C: _

JURADO 3 __________________ / C.C: _

JURADO 4*: _________________/ C.C: _

EN SU SESIÓN EFECTUADA EN: ____________________________________________________ A LAS _

Primera Conclusión: Otorgar la Calificación de: _._ (Si aplica)

AUTOR: ________________________________ /C.C:_

__________ _ _______