UNIVERSIDAD ESTATAL PENINSULA DE SANTA ELENA FACULTAD DE SISTEMAS Y TELECOMUNICACIONES ESCUELA DE INFORMATICA NOMBRE: JORGE LUIS TIGRERO ALVARADO

CARRERA: INGENIERIA EN SISTEMAS PARALELO: 3/1 FECHA: 18/06/2010 ASIGNATURA: ANALISIS Y DISEO DE SISTEMAS DOCENTE: MAYRA DIAZ DEBER DE ANALISIS Y DISEO DE SISTEMAS SISTEMAS DE PRUEBAS Un sistema de pruebas implica la operacin o aplicacin del mismo a travs de condiciones controladas y la consiguiente evaluacin de la informacin. Las condiciones controladas deben incluir tanto situaciones normales. El objetivo del sistema de pruebas es encontrar un error para determinar situaciones en donde algo pasa cuando no debe de pasar y viceversa. En una palabra, un sistema de pruebas esta orientado a destacar. Para la planeacin de las pruebas que se van a aplicar al sistema evaluador, se integraron los distintos tipos de pruebas que se explicaran a continuacin:

PRUEBAS DE CAJA NEGRA: el sistema de pruebas de caja negra no considera la codificacin dentro de sus parmetros a evaluar, es decir, que no estn basadas en el conocimiento del diseo interno del programa estas pruebas se enfocan en los requerimientos establecidos y en la funcionalidad del sistema. PRUEBA DE CAJA BLANCA: al contrario de las pruebas de caja negra, estn se basan en el conocimiento de la lgica interna del cdigo del sistema. Las pruebas contemplan los distintos caminos que se pueden generar gracias a las estructuras condicionales, a los distintos estados del mismo, etc.

PRUEBAS DE INTEGRACION: Las pruebas de integracin buscan probar la combinacin de las distintas partes de la aplicacin para determinar si funcionan correctamente en conjunto. Esto es til para ver como se comunica los servlets con las paginas d HTML.

PRUEBAS DEL SISTEMA: Son similares a las pruebas de caja negra, solo que ests buscan probar al sistema como un todo. Estn basadas en los requerimientos generales y abarca todas las partes combinadas del sistema. Haciendo uso de las pruebas explicadas anteriormente, se definieron tres rubros en base a los cuales se van a definir los puntos a evaluar a definir los puntos a evaluar. Estos rubros son los siguientes:

Pruebas De Contenido: Estas pruebas como su nombre lo indica, buscan verificar que el contenido del sistema sea coherente y consiste a la vez. Tambin se debe de verificar que las palabras usadas para transmitir una idea al usuario sean las adecuadas y que la idea transmitida sea la misma. Gran parte de las pruebas de contenido realizadas al sistema estn enfocadas a los cuestionarios (Apndice A) y los glosarios (Apndice D) ya que el objetivo principal del sistema es la interaccin del usuario con los cuestionarios.

Pruebas De Funcionalidad: Este tipo de pruebas examina si el sistema cubre sus necesidades de funcionamiento, acorde a las especificaciones de diseo. En ella se debe verificar si el sistema lleva a cabo correctamente todas las funciones requeridas, se debe verificar la validacin de los datos y se debe realizar pruebas de comportamiento ante distintos escenarios. Estas pruebas deben estar enfocadas a tareas, a lmites del sistema, a condiciones planeadas de error y de exploracin. Para estas pruebas usamos los esquemas de pruebas de caja negra ya que nos interesa saber si funciona o no, independientemente de la forma en que lo haga.

Pruebas De Usabilidad: Las pruebas realizadas en este rubro tienen la finalidad de verificar que tan fcil de usar es un sistema. Las pruebas de usabilidad deben verificar aprendizaje (que tan fcil es para los usuarios realizar tareas bsicas la primera vez que tienen contacto con el sistema ), eficiencia (una vez que los usuarios han aprendido algo del sistema, que tan rpido pueden llevar a cabo las tareas ), manejo de errores (cuantos errores comete el usuario, que tan graves son estos y que tan fcil es para el usuario recuperarse de ellos) y grado de satisfaccin (que tan satisfactorio es usar el sistema). Para obtener resultados realistas en este tipo de pruebas, es importante dejar que las personas que estn probando el sistema resuelvan los problemas que se les presentan por s mismo, ya que si uno no los ayuda, ya est contaminados las pruebas [Nielsen 03]. Segn Jacob Nielsen, para identificar los problemas ms importantes de un sistema es suficiente que lo prueben 5 personas.