Capítulo 5 Pruebas de la aplicación desarrollada

Capítulo 5 Pruebas de la

aplicación desarrollada

“No se debe juzgar a un hombre por sus cualidades, sino por el uso que hace de ellas.”

Francois de la Rochefoudcauld. Escritor francés.

Plataforma Ninbox: aplicación web para integración de servicios e-Learning

Capítulo 5 Pruebas de la aplicación desarrollada

5.1 IntroducciónEn este capítulo se realizarán las pruebas de las aplicaciones desarrolladas y se

expondrán los resultados obtenidos y las conclusiones.

Todas las pruebas que se describen en los apartados posteriores están realizadas

tanto en un servidor Windows como Linux y los navegadores utilizados han sido Internet

Explorer 5.5, Mozilla Firefox 1.5 y Opera 9.

No obstante las capturas expuestas en los apartados corresponden a la prueba en un PC

bajo Windows XP con el servidor Apache wamp y utilizando el navegador Mozilla Firefox

1.5.

Carlos Serrano Sánchez



5.2 Ejecución del núcleo en el servidorEn esta sección se realizarán las pruebas del núcleo de la plataforma Ninbox,

como se ha explicado la plataforma está diseñada para funcionar como un sistema de

educación online.

La aplicación desarrollada solo corresponde con el núcleo de esta plataforma,

por tanto las pruebas que se realizarán estarán centradas en la autenticación de usuarios,

seguridad de acceso, control de privilegios en los foros y monitorización de la plataforma.

Antes de comenzar las pruebas se debe configurar el sistema de acuerdo a las

condiciones del test. Dado que no existe interfaz para crear, modificar o eliminar foros,

usuarios y privilegios toda esta operación se debe realizar directamente sobre la base de

datos accediendo por medio del PHPmyadmin del servidor.

5.2.1 Consideraciones previas

En esta sección se configura el marco bajo el cual se realizarán las pruebas al

núcleo. En el capítulo 7 Referencia de códigos y planos se puede ver los diferentes campos

de las tablas empleadas.

En primer lugar configuramos el sistema en general modificando config.php.

Insertamos el nombre del sistema, la hora por defecto es GMT+0 , no se detecta cambio

horario y se configuran los demás valores de datos como son URL, metaKeys, mail del root,

login y contraseña de la base de datos...

A continuación se debe observar que la tabla grupos del sistema posee los

grupos por defecto cuando se ejecuta la instalación. Estos grupos corresponden a la

división de usuarios mínima que el sistema soporta. Con estos grupos hacemos una

división entre usuarios que se han registrado, pero aún no han activado la cuenta, usuarios




normales, usuarios moderadores.... dependiendo de los privilegios que tengan.

Esta tabla se genera por defecto como indica la siguiente figura (por claridad no

se han insertado todos los campos de la tabla en la imagen):

El grupo SUPERUSER tiene como límite un usuario. Es el grupo del

superusuario, tiene todos los privilegios.

El grupo ADMIN está destinado a todos los usuario administradores, tiene

todos los privilegios de administración sobre el foro, pero no puede crear grupos con todos

los privilegios, ni insertar a ningún usuario a este grupo. ( Esta política se extiende a todos

los grupos, ningún grupo tiene poder para crear grupos con los mismos privilegios que él

mismo o insertar personas en grupos del mismo nivel, sólo el SUPERADMIN puede

realizar esta tarea o grupos que estén por encima en la jerarquía).


Figura 25: Tabla de grupos por defecto



El grupo SUPERMOD está destinado a usuarios moderadores con algunos

privilegios de administración, es decir, puede entrar en algunas secciones del panel de

control del sistema. No pueden crear a otros supermoderadores.

El grupo MOD está destinado a moderadores que sólo tienen acceso al panel de

moderación del foro, pero no pueden borrar físicamente del sistema. Solo pueden realizar

borrado lógico ( el foro o hilo se marca como borrado en la tabla y deja de ser visible para

usuarios normales) .

El grupo REGISTERED está destinado a todos los usuarios que hayan activado

su cuenta. Por tanto todo usuario registrado pertenece al menos a este grupo.

El grupo AWAITING está destinado a usuarios que se han dado de alta en el

sistema, pero aún no han activado su cuenta.

El grupo BANNED está destinado a usuarios cuyas cuentas han sido

bloqueadas, por tanto no pueden registrarse.

El grupo NOTREGISTERED está destinado a todos los usuarios del sistema que

esta visitándolo sin registrarse. Por tanto, toda persona que visite el sistema es

obligatoriamente perteneciente a al menos este grupo.

Todos los grupos tienen unos privilegios por defecto que determinan las

operaciones que pueden realizar en el sistema ( instalar mod, borrar usuarios...) u

operaciones que pueden realizar en los foros en los cuales no existan privilegios explícitos

sobre estos grupos.

Como podemos observar, SIEMPRE se pertenece al menos a un grupo, de esta

forma las operaciones, lugares que se pueden visitar... están determinados por los

privilegios de lo(s) grupo(s) del usuario.




A continuación se describen los usuario que existen en el sistema que se ha

creado para realizar las siguientes pruebas:

El primer usuario tiene login carlos y contraseña almacenada mediante un hash

md5. Tiene el lenguaje italiano por defecto y la fecha tipo mm//dd//yyyy. La hora GMT+1

y tiene la cuenta activada por lo tanto tendrá acceso a registrarse. Pertenece al grupo

REGISTERED y MOD.

El otro usuario tiene login tony y contraseña también almacenada mediante

hash md5. Su lenguaje por defecto es inglés y la ficha tipo dd//mm//yyyy. La hora es

GMT+0 y cuenta activada. Pertenece al grupo REGISTERED.

Cabe destacar que se han realizado ya varias pruebas y sus contadores de visitas

y demás datos estadísticos no están a 0.

Por últimos se ha creado una estructura de foros para probar el sistema cuyo

esquema es el siguiente:

➢ Foro 1: Programación PHP

○ Foro 1.1: Subforo de programación PHP

➢ Foro 2: Programación Javascript

➢ Foro 3: Nuevo

○ Foro 3.1: Subforo de Nuevo

Solo se han introducido privilegios para el foro Nuevo y para el Foro de

Programación Javascript, por lo tanto a todos los demás foros se les aplicará los privilegios

por defecto de los grupos a los que pertenezca el usuario.

Los privilegios para el foro Nuevo se han aplicado para el grupo MOD al cual se

le han quitado todos los privilegios de moderación.




Los privilegios para el foro Foro de programación Javascript que se han

aplicado para el grupo NOTREGISTERED es de negación de todos los privilegios, es decir

no es visible.

Para el grupo REGISTERED se le han aplicado todos los privilegios de moderación.

En la tabla security se ha activado que no se permite el acceso a la dirección IP

127.0.0.2. En la tabla monitor se ha activado que se monitoricen los movimientos del

usuario tony.

Una vez realizadas estas operaciones comienzan las pruebas de acceso al

sistema que se describen en el apartado siguiente.

5.2.2 Pruebas realizadas y resultados

PRUEBA 1

En primer lugar se realiza el acceso al sistema, para ello se accede a la página de

pruebas elaborada, llamada displayforum.php. Esta página recibe por parámetro GET el id

del foro que se desea visitar, en caso de no ser un id válido o no tener permisos

redirecciona a la página de error.php.

En las pruebas que se realizan a continuación se accede a

displayforum.php?id=1, es decir, al primer foro que es Programación PHP.




RESULTADO 1

Como se puede observar el acceso ha sido permitido, puesto que el grupo por

defecto NOTREGISTERED ha sido aplicado al usuario visitante. Los privilegios que se

poseen por defecto, son solo de visualización, como refleja el cuadro resumen de

privilegios.

Además el menú de navegación muestra todos los foros que son visibles por los

usuarios NOTREGISTERED. Previamente se configuró el foro 3 Nuevo para que no fuese

visible, por este motivo no aparece al igual que el subforo que hereda las propiedades.

Por último se observa que se ha aplicado el lenguaje por defecto del sistema que era

español y la hora que correspondía a GMT+1.

PRUEBA 2

A continuación se registra el usuario carlos y deja marcado la casilla Recordar

sesión.

La figura siguiente muestra el resultado:

RESULTADO 2


Figura 26: Pruebas del núcleo 1, acceso al foro 1 como visitante



Una vez registrado, el usuario carlos pertenece al grupo REGISTERED y MOD,

por lo tanto los privilegios totales se calculan como un OR de ambos grupos.

Como se puede observar son visibles todos los foros y subforos como era de esperar.

Además automáticamente el sistema ha cargado el lenguaje italiano y se ha

fijado el horario a GMT+1.

Se tienen todos los privilegios más el de moderación.

A continuación se comprueba el acceso al foro Nuevo, aunque pertenece al

grupo MOD no tiene ningún poder de moderación puesto que se ha expresado

explícitamente en la entrada de privilegios para este foro.

Se comprueba además que si se cierra el navegador, y se abre de nuevo la

página, la sesión es recordada y automáticamente queda registrado como carlos.

PRUEBA 3

A continuación se cierra la sesión de carlos, se cierra el navegador y se abre de

nuevo la página, se comprueba que la sesión ya no es recordada.

Se registra con el usuario tony que pertenece al grupo REGISTERED y se accede al foro 1


Figura 27: Pruebas del núcleo 2, acceso de usuario Carlos



Programación PHP.

A continuación se accede a foro 2 Programación Javascript.

RESULTADO 3

En el primer caso el usuario tony no tiene permisos de moderación , sin

embargo en el caso de foro 2 en el cual se le indicó que los usuarios REGISTERED tienen

permisos de moderación, se puede comprobar que efectivamente posee dicho privilegio.

Además el sistema ha cargado automáticamente el lenguaje inglés y el horario GMT+0.


Figura 28: Pruebas del núcleo 3, acceso con usuario tony

Figura 29: Pruebas del núcleo 3, acceso con usuario tony a foro 2



También se comprueba que recuerda el tiempo de la última sesión, número de

visitas...

PRUEBA 4

Como se describió al inicio, se ha configurado el sistema para la monitorización

del usuario tony, además el módulo de seguridad del núcleo debe haber indicado que se ha

compartido PC e IP 127.0.0.1.

RESULTADO 4

Resultado de la tabla ipaddress que registra todas las IP's visitantes. Registra

todas las Ips de los usuarios.

La tabla monitor_tagboard ha lanzado los siguientes mensajes:

➢ Computer shared: carlos,tony

➢ IP 127.0.0.1 shared: carlos,tony

➢ Monitoring tony: Access to /NINBOX/model/displayforum.php?id=4 with IP:

127.0.0.1

➢ Monitoring tony: Access to /NINBOX/model/displayforum.php?id=2 with IP:

127.0.0.1

Los dos primeros mensajes advierten al administrador que los dos usuarios han


Figura 30: Pruebas del núcleo 4, tabla IPaddress



compartido misma IP y mismo equipo.

Los otros dos mensajes son el resultado de la monitorización del usuario tony.

PRUEBA 5

Ahora se inserta en la tabla security una entrada de tipo login y valor tony. Esto

quiere decir que no se le permite el acceso al usuario tony.

RESULTADO 5

Si se intenta acceder con el usuario tony al sistema automáticamente se

redirecciona a la página de error marcando el código oportuno. Para ver más información

sobre los distintos códigos de errores véase el punto 7.7 Tabla de errores.

Este es el mensaje que muestra la página de error:

error:1200 desde el server: localhost con ip:127.0.0.1puerto:1344 script actual:c:/wamp/www/ninbox/model/error.php

5.2.3 Conclusiones

El sistema proporciona un marco perfecto de autenticación y control de acceso

para desarrollar aplicaciones de gestión de contenidos web.

Su funcionamiento basado en una autenticación centralizada satisface plenamente las

condiciones de seguridad de una web de contenidos. Además el sistema de monitorización

que incluye hacen que el administrador tenga poder absoluto sobre todos los usuarios y

control total sobre el sistema, manteniéndose en todo momento informado de posibles

irregularidades que puedan ocurrir.

Como se ha explicado, la aplicación que está diseñada para ser montada sobre

este núcleo es un sistema web para la educación online basado en una navegación de foros.




De este modo el diseño de la tabla de privilegios otorga infinidad de posibilidades de

configuración, pudiendo el administrador personalizar el sistema hasta el último detalle.

Con este sistema se ha hecho posible que una misma aplicación pueda tener múltiples

aplicaciones y con estructuras completamente distintas.

En todos los casos las pruebas para las cuales ha sido programado este núcleo

han sido pasadas satisfactoriamente, y cabe destacar que el espacio en disco y el tiempo de

ejecución son mínimos.

Se adjunta una captura con el modo debugger activado donde se puede apreciar el tiempo

de ejecución de una página.


Figura 31: Pruebas del núcleo, modo debugger activado



5.3 Ejecución del editor WYSIWYG


En esta sección se realizan las pruebas de funcionamiento sobre el editor

WYSIWYG que se explicó en el capítulo 3.5.2 Editor WYSIWYG.

Para ello se ha insertado en una página HTML cuyo contenido es el siguiente.

Entre las etiquetas HEAD:

<script type="text/javascript" src="ninbox.js"></script><script type="text/javascript"> _editor_url = "./"; var editor = null; function initEditor() { var config = {

"interface" : "full", //full,reduced,minimalist"allowHTML" : "false","mode" : "WYSIWYG","allowchangemode" : "true"};

function ini(){ editor = new WYSIWYG_NINBOX("wysiwyg",config);

editor.generate(); return false; } setTimeout(ini,250); }</script>

Al inicio se carga el archivo ninbox.js que contiene el código Javascript que

genera el editor WYSIWYG.

A continuación se establecen las variables de entorno para su funcionamiento:

➢ _editor_url: dirección relativa de acceso al archivo ninbox.js




➢ config: variable de configuración del editor

○ interface: tipo de interfaz generada: completa, reducida o minimalista

○ mode: modo inicial de funcionamiento: WYSIWYG o modo edición

○ allowchangemode: permitir cambio entre modos de funcionamiento.

Entre las etiquetas BODY:

<body onload="initEditor()"><textarea id="wysiwyg" name="wysiwyg" rows="10" style="width:600px ">hola mundo</textarea>


PRUEBA 1

Inserción de todos los elementos que permite el editor WYSIWYG.

La siguiente imagen muestra la información insertada:




A continuación se muestra el código HTML que genera renderizado ( como se visualiza

todo el contenido antes insertado) :


Figura 32: Pruebas del editor WYSIWYG 1, texto formateado




Figura 33: Pruebas del editor WYSIWYG 1, visualización del

contenido



RESULTADO 1

Se puede observar como los resultados son completamente los buscados.

Su uso es intuitivo y similar al de cualquier procesador de texto y el tiempo de carga es

mínimo. Todas las pruebas han sido realizadas sobre los navegadores IE 5.5+, Firefox 1.5+

y Opera 9+ , y en todos los casos los resultados han sido positivos.

PRUEBA 2

Se realiza un cambio de modo WYSIWYG a Modo Edición con todo el contenido

que se ha insertado en la prueba 1.

A continuación se muestra la captura del resultado.


Figura 34: Pruebas del editor WYSIWYG 2, modo edición



RESULTADO 2

La conversión a Ncode es en todo momento correcta, su conversión a HTML de

nuevo es adecuada y en ningún caso se pierde información permitida ( código HTML que

se permite y para el cual existe una conversión directa a Ncode).

5.3.3 Conclusiones

El editor WYSIWYG Ninbox se ha convertido en una aplicación robusta de uso

cada vez más extendido ( ha sido compartido como software libre en varios foros de

programación ) por varios motivos.

Uno de ellos es su portabilidad, es capaz de ejecutarse en una gran variedad de

navegadores, propiedad que resulta novedosa en el caso de los navegadores Opera.

El otro motivo es su rápida inicialización y conversión entre códigos.




5.4 Ejecución de la WebConference: Talkinbox


En este apartado se realizarán las pruebas sobre la webConference Talkinbox,

para ello se comenta a continuación la configuración que se utilizará.

En primer lugar se crea una sesión de webConference, llamada Test, con

moderador Carlos Serrano y tiempo de inicio y duración acorde al momento de la prueba.

Para ello se necesita realizar una inserción de estas características en la tabla

talkinbox_session.

Además se realizan varias entradas de datos en la tabla talkinbox_slides que contienen las

diapositivas que el moderador puede mostrar a los usuarios.

Se comprueba que la tabla talkinbox_security no tenga ningún contenido relacionado con

los usuarios que se emplean en la prueba, puesto que esta tabla sirve para prohibir el

acceso a determinados usuarios.

Toda la información de estas tablas se encuentran en el punto 7.6 Planos de base de datos.


La prueba realiza consiste en abrir una página creada específicamente para la

prueba que tiene integrado el sistema talkinbox y que recibe por parámetro GET el nombre

de usuario, fijando la sesión a la creada en el punto previo.

Para ello las URLs introducida en los dos navegadores que se utilizará para las pruebas

serán las siguientes:

MODERADOR: model/TalkInBox/index.php?login=Carlos%20Serrano

USUARIO: model/TalkInBox/index.php?login=Antonio%20Sierra




A continuación se muestran las capturas del inicio de sesión de ambos

navegadores, comenzando por la ventana del moderador:


Figura 35: Pruebas de la WebConference, interfaz moderador



Las pruebas que se realizan son las de comunicación, otorgación de turno de

palabra para el usuario, envío de mensajes privados, expulsión de usuario y posterior

intento de acceso por el mismo.

La captura de dicha prueba se muestra a continuación en la ventana del cliente:


Figura 36: Pruebas de la WebConference, interfaz usuario



Se puede observar que la comunicación es correcta, incluso en el envío de texto

HTML con imágenes, vídeos...,

El usuario Antonio Sierra aparece en la lista de usuarios con un color amarillo,

indicando que tiene turno de palabra. Además contiene el editor WYSIWYG que le permite

escribir texto. A continuación se muestra la carga de diapositivas en el lado del moderador

y la expulsión del usuario Antonio Sierra


Figura 37: Pruebas de la WebConference, comunicación con usuario



A continuación se muestra la captura del resultado del intento de acceso del

usuario Antonio Sierra después de haber sido expulsado por el moderador:

Como se puede observar el usuario no ha podido iniciar la sesión, esto ha sido

producido por la inserción de una entrada en la tabla talkinbox_security que es consultada

al inicio de toda sesión. En caso de que exista una entrada en esta tabla con el login

correspondiente en la sesión actual y relacionada con el usuario que intenta iniciar sesión


Figura 38: Pruebas de la WebConference, carga de diapositivas

Figura 39: Pruebas de la WebConference, expulsión de un usuario

Figura 40: Pruebas de la WebConference, intento de acceso de usuario expulsado



se rechaza la conexión con el servidor.

Además de estas pruebas, se ha realizado comunicación con varios usuarios,

creación de usuario invitados, solicitud de prorroga ( habilitado para el moderador cuando

resten menos de 10 minutos para el fin de sesión ), cierre de sesión...

5.4.3 Conclusiones

El sistema talkinbox es un sistema que tiene una respuesta en tiempo y carga del

procesador excelente.

Las pruebas de carga se han realizado con 9 usuarios conectados en una misma

máquina y con tiempos de retraso de los mensajes de menos de 2 segundos en todos los

casos.

Esta eficiencia y robustez ha sido posible a la creación de los refrescos de información

mediante iframes, es decir, un frame oculto que se actualiza cada segundo y que realiza

consulta en la base de datos para la comunicación de información.

En la versión previa de esta aplicación, este proceso se realizaba mediante el uso de AJAX,

que como se comentó en puntos anteriores, es solo aconsejable en situaciones que no

requieran consultas repetitivas y con transferencia de cierto volumen. En esta versión de

AJAX el servidor no soportaba más de 3 usuarios sin que el retraso en la comunicación

fuese considerable.




5.5 ConclusionesLas aplicaciones realizadas conforman por una parte el esqueleto sobre el que

montar el sistema completo de e-learning, proporcionando una plataforma de

autenticación, monitorización y control de privilegios.

Por otro lado, el editor WYSIWYG ofrece la ventana más importante en la

comunicación web, es decir, el punto de unión entre el usuario y el sistema.

Por este motivo, se ha considerado como prioridad su programación e implementación,

suponiendo un gran punto realizado en el proceso completo de elaboración.

Por último, Talkinbox propone una aplicación novedosa sostenida por una

tecnología que hasta entonces ofrecía poca eficiencia en este tipo de comunicación.

Como conclusión final, la realización de estas aplicaciones ha intentado abarcar

los 3 puntos que se han considerado más importante, una vez diseñado todo el sistema:

➢ Cimientos del sistema ( robustez y solidez )

➢ Punto de comunicación ( Efectividad, flexibilidad y elegancia )

➢ Un paso más adelante en las aplicaciones web ( Innovación y versatilidad )

Con estas aplicaciones, el diseño del sistema y la premisa de cumplir todas las

recomendaciones de la W3C, siempre intentando innovar manteniendo la calidad y la

estructuración de la programación orientada a objetos; el sistema Ninbox se presenta como

una aplicación web digna de representar la idea de web 2.0.





Documents

Capítulo 5 Pruebas de la aplicación desarrollada