14
PRUEBAS DEL SISTEMA Lee atentamente las indicaciones, desarróllalo y envíalo por el mismo medio. En un documento en Word redacte documento sobre: a. El mecanismo de generación de tablas ortogonales para la prueba de datos. b. Un sistema Cliente/Servidor que le sea familiar. Desarrolle un conjunto de escenarios de usuario y genere un perfil operacional para el sistema. El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos, pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos de diseño y desarrollo, debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantícela calidad. Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los “costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pueden costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos.

Pruebas Del Sistema

Embed Size (px)

DESCRIPTION

pruebas de sistema

Citation preview

Page 1: Pruebas Del Sistema

PRUEBAS DEL SISTEMA

Lee atentamente las indicaciones, desarróllalo y envíalo por el mismo medio.En un documento en Word redacte documento sobre:a. El mecanismo de generación de tablas ortogonales para la prueba de da-tos.b. Un sistema Cliente/Servidor que le sea familiar. Desarrolle un conjunto de escenarios de usuario y genere un perfil operacional para el sistema.

El desarrollo de sistemas de software implica una serie de actividades de produc-ción en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos, pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos de diseño y desarrollo, debido a la imposibilidad huma-na de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantícela calidad. Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación.

La creciente percepción del software como un elemento del sistema y la importan-cia de los “costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organiza-ción de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo to-tal de un proyecto en las pruebas. En casos extremos, las pruebas del software pa-ra actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pueden costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos.

PRUEBA DE LA TABLA ORTOGONAL

Hay muchas aplicaciones en que el dominio de entrada es relativamente limitado. Es decir, el número de parámetros de entrada es pequeño y los valores de cada uno de los parámetros están claramente delimitados. Cuando estos números son muy pequeños (por ejemplo, 3 parámetros de entrada tomando 3 valores diferen-tes), es posible considerar cada permutación de entrada y comprobar exhaustiva-mente el proceso del dominio de entrada. En cualquier caso, cuando el número de valores de entrada crece y el número de valores diferentes para cada elemento de dato se incrementa, la prueba exhaustiva hace impracticable o imposible.

La prueba de la tabla ortogonal se aplica a problemas donde el dominio de entrada es relativamente pequeño pero demasiado grande para posibilitar pruebas exhaus-tivas. El método de prueba de la tabla ortogonal nos permite encontrar errores aso-

Page 2: Pruebas Del Sistema

ciados con fallos localizados. Estas pruebas detectan y aíslan todos los fallo de mo-dalidad simple (un fallo de modalidad simple es un problema que afecta a un solo parámetro); detecta todos los fallos de modalidad doble (un fallo de modalidad do-ble es en el que están afectados los parámetros que intervienen conjuntamente); además pueden asegurar la detección de fallos de modalidad múltiple. Concluyen-do que un arreglo ortogonal tiene la propiedad de balance, esto es, para cada pará-metro (par de columnas) todas las combinaciones de parámetro-nivel ocurren la misma cantidad de veces.

Las pruebas de software planificadas con arreglos ortogonales son basada funda-mentalmente en utilizar criterios de diseños de expertos cuyo objetivo es optimizar la cantidad de pruebas a realizar para lo que se pueden utilizar software o tablas que están disponibles para la identificación del número de pruebas a ejecutar te-niendo el probador (ingeniero de pruebas) la tarea de determinar el nivel tipo de prueba en base al orden de las iteraciones, tipo de proyecto, experiencias anterio-res y otros estudios de casos reportados en la literatura.

El propósito que se tiene en el diseño del producto es encontrar aquella combina-ción de factores que nos proporcione un desempeño más estable y costo de desa-rrollo más bajo.

Un arreglo ortogonal se puede comparar con una replicación factorial fraccionada, de manera que conserva el concepto de ortogonalidad y contrastes. Un experimen-to factorial fraccionado es también un arreglo ortogonal.

Taguchi desarrolló una serie de arreglos particulares que denominó:

La (b)C

Donde:

a = Representa el número de pruebas o condiciones experimentales que se toma-rán. Esto es el número de renglones o líneas en el arreglo.

b = Representa los diferentes niveles a los que se tomará cada factor.

c = Es el número de efectos independientes que se pueden analizar, esto es el nú-mero de columnas.

ARREGLOS ORTOGONALES PARA EXPERIMENTOS A DOS NIVELES

En esta sección, se analiza qué son, cómo se usan y cuáles son los arreglos orto-gonales más importantes para experimentos en los que cada factor toma dos nive-les.

Un arreglo ortogonal es una tabla de números. Como ejemplo de un arreglo ortogo-nal tenemos el siguiente:

Page 3: Pruebas Del Sistema

F A C T O R E S (c)No. (a) A B C Resultado

1 1 1 1 Y12 1 2 2 Y23 2 1 1 Y34 2 2 1 Y4

1 , 2 = Niveles de los Factores (b)

De acuerdo con la notación empleada por Taguchi al arreglo mostrado como ejem-plo, se le llama un arreglo L4, por tener cuatro renglones.

En general, para un arreglo a dos niveles, el número de columnas (efectos o facto-res) que se pueden analizar, es igual al número de renglones menos 1.Taguchi ha desarrollado una serie de arreglos para experimentos con factores a dos niveles, los más utilizados y difundidos según el número de factores a analizar son:

Serie de arreglos para experimentos con factores a dos niveles.

ARREGLOS ORTOGONALES PARA FACTORES CON INTERACCIONES

En los procesos de prueba de software y fundamentalmente al realizar las pruebas de caja negra o pruebas de comportamiento se producen interacciones entre los procesos o datos de entradas. Cuando el efecto de un factor depende del nivel de otro factor, se dice que existe una interacción entre los factores. Al planificar las pruebas se encuentran los siguientes factores “Tipo de operación”(Factor A) y la “Naturaleza contable de la operación” (Factor B), los cuales afectan la variable de respuesta (contabilización de la operación) impidiendo de esta forma realizar co-rrectamente los comprobantes contables al termino de cada operación.

Existe interacción entre los factores principales figura No. 1. En el caso de una ope-ración bancaria, al observar la grafica analizamos cuál sería el efecto del “Tipo de operación” (Factor A) sobre la correcta contabilización de los hechos contables, en-tonces concluimos que depende de la naturaleza de la operación. Si el usuario selecciona “Debito” la operación disminuye el saldo a contabilizar, en caso con-trario o sea, si el usuario selecciona “Crédito”, la operación incrementa el saldo a contabilizar y por lo tanto hay un aumento de la cuenta contable a la que tri-bute visualizando de esta forma el efecto del factor “A” sobre el “B”.

Page 4: Pruebas Del Sistema

Las dos líneas son paralelas, no El efecto de A depende del nivel de B

Existe interacción entre los factores. Y viceversa. El efecto de A no es consisten-te.

Existe interacción

Al incluir interacciones en un arreglo ortogonal debemos tener presente el análisis realizado por Taguchi:

a) Los arreglos ortogonales a utilizar para los casos con interacciones, son exactamente los mismos que se usan para el caso sin interacciones.

b) Al asignar dos factores A y B por ejemplo a ciertas columnas, automáti-camente la interacción de esos dos factores AXB se reflejará en otra co-lumna del arreglo. Por lo tanto, esta tercera columna ya no podrá ser utilizada para algún otro factor o interacción a menos que se pueda suponer la interac-ción AXB como inexistente.

c) Una interacción significante que se desee probar, tomará una columna y en consecuencia un grado de libertad. Por lo tanto, si deseamos analizar el efecto de seis factores y cuatro de las interacciones entre ellas, requeri-remos por lo menos de diez grados de libertad, esto es de diez colum-nas, o sea un arreglo L16 y no un arreglo L8. Que sería suficiente sin interac-ciones.

d) Se deberá tener cuidado especial en la manera como se asignan los fac-tores a las columnas, para que sus interacciones no se confundan con otros factores principales u otras interacciones que también deseamos probar.

En cuanto a software se refiere planificar o probar todas las posibles variantes que se solapan traería como consecuencia una complicación adicional por la presencia de interacciones. Para lidiar con estas, los expertos en la materia hacen las observaciones siguientes (Taguchi, 1992).

Por lo general existen pocas interacciones dentro de las múltiples posibles entre factores.

El efecto de las interacciones sobre la variable de respuesta, es por lo general menor que el efecto de los factores individuales solos.

Recuerde que algunos arreglos ortogonales, le permiten analizar un pro-blema sin preocuparse por las interacciones. El L12 es un ejemplo de ellos.

Page 5: Pruebas Del Sistema

Se sugiere que, en caso de dudas sobre las interacciones, siempre sea preferible incluir más factores, en lugar de interacciones. Si estas últimas no son muy fuertes, se pueden considerar como ruido.

De todos los factores que afectan un proceso, se pueden extraer dos gru -pos: Factores de ruido. Aquellos que no podemos, querremos o deseamos contro-lar, y más bien deseamos que nuestros procesos y productos sean insensi-bles a su impacto. Factores de diseño. Aquellos que si podemos controlar en nuestro proceso de producción, y deseamos encontrar a qué nivel operarlos, a fin de optimizar el producto o proceso, esto es, que los productos sean de alta calidad y bajo costo (Taguchi, 1992).

Por ejemplo: La GUI (Interfaz Grafica de Usuario) dispone de tres factores (el tipo de operación, la naturaleza contable de la operación y el estado de la misma) para cada uno de estos factores existen dos niveles (no se considera el identificador de la operación por ser tratado por codificación y no pueden ser cambiados por ningún usuario)

Factores y niveles correspondientes a la interfaz

Entonces el número de pruebas será ocho (efecto de elevar el número de niveles a la cantidad de factores). La mejor forma de identificar los errores es realizar las ocho pruebas (prueba exhaustiva), en las pruebas de software el número de casos de prueba que se deben planificar teniendo en cuenta la cantidad de factores y niveles de los mismos hace impracticable ejecutar todas las combinaciones. Este método permite racionalizar el número de pruebas sustancialmente, con

Page 6: Pruebas Del Sistema

solo cuatro pruebas según muestra la tabla siguiente, se puede garantizar encon-trar el mayor número de errores, disminuyendo el tiempo y el esfuerzo de de -sarrollo del software.

De acuerdo con la notación empleada por Taguchi el arreglo mostrado para el caso de estudio se le llama arreglo L4 representado en la tabla anterior, por tener cuatro renglones, los cuales son equivalentes al número de pruebas que se desarrollaran.

Al concluir las pruebas planificadas las estadísticas demostraron que de los siete errores detectados al realizar las pruebas planificadas según la tabla ortogonal, el 14.29 % fueron detectados sin interacción principales entre los factores (datos de entrada). Es importante observar que el 57.14 % de los errores se detectaron con interacciones dobles y el 28.57 % con las interaccione s triples, lo que demuestra que las técnicas de Taguchi aseguran al menos el 90 % de detección de errores re-duciendo considerablemente las pruebas a desarrollar.

En la siguiente tabla puede observarse que los parámetros de detección de errores continúan siendo mayores del 80 % para las interacciones dobles y triples:

Se concluye entonces que después de desarrollar un conjunto de pruebas utilizan-do las técnicas de Taguchi para la mejora continua de la calidad de los pro -ductos y procesos, en el caso específico del software de computadoras se constató que al aplicar la tabla ortogonal se reduce considerablemente el tiem-po de pruebas obteniendo además resultados positivos en la calidad y confiabilidad del software. Al detectar el mayor número de errores con sólo revisar las inte-racciones principales se llegan a obtener aplicaciones más robustas y capaces de cumplir con los objetivos de los requisitos funcionales pactados con el cliente en la fase inicial.

Page 7: Pruebas Del Sistema

SISTEMA CLIENTE/SERVIDOR

En el mundo de TCP/IP las comunicaciones entre computadoras se rigen básica-mente por lo que se llama modelo Cliente-Servidor, éste es un modelo que intenta proveer usabilidad, flexibilidad, interoperabilidad y escalabilidad en las comunica-ciones.

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma.

En el modelo cliente servidor, el cliente envía un mensaje solicitando un determina-do servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio). En un sistema distribuido cada máquina pue-de cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.

La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar muchas tareas, pero con la consideración de que realice aquellas que son más adecuadas a sus características. Si esto se aplica tanto a clientes como servi-dores se entiende que la forma más estándar de aplicación y uso de sistemas Cliente/Servidor es mediante la explotación de las pc’s a través de interfaces gráfi-cas de usuario; mientras quela administración de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los procesos clien-te sólo se ocupan de la interacción con el usuario (aunque esto puede variar). En otras palabras la arquitectura Cliente/Servidor es una extensión de programación modular en la que la base fundamental es separar una gran pieza de software en módulos con el fin de hacer más fácil el desarrollo y mejorar su mantenimiento.

EL LMS MOODLE COMO SISTEMA CLIENTE/SERVIDOR

El LMS (Learning Management System o en español Sistema Administrador de Aprendizaje) Moodlees una aplicación encargada del control y administración de la formación e-Learning.Tiene incorporada herramientas integradas que se utilizan para la creación, gestión y distribución de actividades formativas a través de la Web. Es decir, es una aplicación que facilita la creación de entornos de enseñanza-aprendizaje, integrando materiales didácticos y herramientas de comunicación, co-laboración y gestión educativas.

Page 8: Pruebas Del Sistema

En la imagen siguiente se muestra que hay diferentes elementos de configuración dependiendo del rol del usuario en el curso.

Moodle es una aplicación web creada específicamente por educadores para ayudar al profesorado en su labor de formación en cuanto a desarrollo de contenidos, he-rramientas útiles y ejercicios por Internet con el único fin de apostar por una calidad de enseñanza adaptada al progreso y a las nuevas tecnologías. Además, esta pla-

Page 9: Pruebas Del Sistema

taforma permite una enorme flexibilidad didáctica y un altísimo índice de usabilidad (la curva del aprendizaje en el manejo como alumno no supera las 2 horas).

Las ventajas que ofrece Moodle son múltiples, prioritariamente el respaldo técnico del que dispone así como la gran estabilidad del programa. Este software está for-mado por una tecnología muy sencilla y compatible con otros programas, por lo que es fácil de instalar y sólo requiere que exista para ello una base de datos. El código está escrito en PHP bajo la licencia GPL y se puede modificar de fácilmente para satisfacer así las necesidades de los usuarios.

Por esta razón, es muy apropiado para clases on line e incluso para ser usado en cursos presenciales, en los que las áreas donde se introducen los textos se editan usando HTML, es decir, tan fácil como hacerlo en el editor de texto de Windows. Así, un usuario puede usar, modificar o copiar la información de Moodle siempre y cuando proporcione el código fuente para otros usuarios y no modifique o elimine la licencia original o los derechos de autor de otras personas.

Una vez que se crea el sitio, éste es administrado por un usuario-administrador, que se elegirá durante la instalación de Moodle. La función de la administración se-rá mantener la seguridad pero también delega parte de ella en el resto de los usua-rios, que pueden darse de alta sólo mediante la verificación de una cuenta de co-rreo electrónico, por lo que la tarea resulta muy sencilla para los estudiantes. El ad-ministrador será el que controle la creación de cursos y determine los profesores, asignando usuarios a cada uno de los cursos.

Algunas características funcionales son las siguientes:

a. Es free y Open Source. Tiene licencia GPL.b. Es escalable, se pueden tener cursos con 40.000 estudiantes matriculados.c. Moodle se ejecuta sin modificaciones bajo Unix, Linux, Windows, Mac OS X,

NetWare y otros sistemas operativos que permitan PHP (la mayor parte provee-dores de alojamiento Web lo permiten).

d. Está diseñando de manera modular, y permite un gran flexibilidad para agregar (y quitar) funcionalidades en muchos niveles.

e. Se actualiza muy fácilmente desde una versión anterior a la siguiente. Además, tiene un sistema interno para actualizar y reparar su base de datos cada cierto tiempo.

f. Usa solamente una base de datos (si lo necesita puede compartirla con otras aplicaciones).

g. Usa una completa abstracción de bases de datos, y también es capaz de sopor-tar las principales marcas de bases de datos.

h. Se ha puesto énfasis en una seguridad sólida en toda la plataforma. Todos los formularios son revisados, las cookies encriptadas, etc.

Características de interés para los profesores:

a. Moodle promueve una pedagogía constructivista social (colaboración, activida-des, reflexión crítica, etc.).

b. Es adecuada tanto para las clases totalmente en línea o a distancia, así como para complementar el aprendizaje presencial.

Page 10: Pruebas Del Sistema

c. Tiene una interfaz de navegador de tecnología sencilla, ligera, eficiente, y com-patible.

d. Es fácil de instalar en casi cualquier plataforma que soporte PHP. Sólo requiere que exista una base de datos (y la puede compartir). Se lo puede bajar de la ULR: http://moodle.org/.

e. La lista de cursos muestra descripciones de cada uno de los cursos que hay en el servidor, incluyendo la posibilidad de acceder como invitado.

f. Las listas de los cursos muestran las descripciones de cada curso del servidor, permitiendo el acceso de invitados.

g. Los cursos pueden clasificarse por categorías y también pueden ser buscados. Un dato importantísimo es que un sitio Moodle puede albergar miles de cursos.

h. Los cursos pueden tener categorías y ser buscados.i. La mayoría de las áreas de introducción de texto (recursos, mensajes de los fo-

ros, entradas de los diarios, etc.) pueden ser editadas usando el editor integra-do HTML de tipo WYSIWYG.

El administrador principal es quien tiene el control de todos los usuarios. El admi-nistrador principal es el único que puede asignar o eliminar otros usuarios para que sean administradores. La dirección de correo principal de los administradores reci-birá todos los correos devueltos (rechazos debido a direcciones inválidas) y ade-más, los otros administradores no podrán editar el perfil del usuario administrador principal.

ROLES DE USUARIOS

Para la asignación de roles el alta en el sitio no es suficiente crear las cuentas de usuarios; debe ir acompañada del alta en un “curso”. Para dar de alta a los docen-tes o estudiantes dentro de un módulo, hay que asignar los roles correspondientes para cada usuario en cada módulo.

a) Rol Profesor: El rol profesor y estudiante está unido a un curso específico en MOODLE. Ser profesor en un curso no le da privilegios extra en otro, debe ser explícitamente añadido al curso como profesor, o como estudiante, o no tendrá acceso de ninguna otra forma.

Tipos de rol de profesor:o Existe el rol de profesor creador de curso, es un profesor con opciones aña-

didas, es decir que tiene otros tipos de privilegios.o El profesor con edición podrá gestionar contenido, publicar y figurará dentro

de la publicación del curso como profesor.o El profesor sin edición solo podrá observar los contenidos publicados y figu-

rará dentro de la publicación del curso como profesor.b) Rol Estudiante: Los estudiantes pueden manejar todo lo que se les ofrece en

un curso, comunicarse con su profesor, participar en foros y chat, consultar re-cursos, hacer actividades, etc. Pero no pueden modificar nada del curso.

c) Rol Invitado: MOODLE tiene una cuenta de invitado predefinida. Las personas que visitan el sitio pueden entrar como invitados usando el botón para "Entrar como invitado" en la pantalla de entrada al sitio y entrar a cualquier curso que permita el acceso a los invitados. Adicionalmente, los usuarios que hayan entra-do al sitio pueden entrar a cualquier curso que permita el acceso a invitados sin que se les pida inscribirse.