plan de pruebas de delta pensum 1

Sory Gómez # 93-25329 Guly De Sousa # 94-26272 Julio Rodríguez # 95-27920 Carelys Cárdenas # 95-27239 Richard Pérez # 95-27828

Carlos Ascanio # 94-26074Javier Blanco # 94-26127Luis Rojas # 94-26884Faustino Ubiaga #94-26995

Plan de Pruebas de Delta Pensum 1.0 (reducido)

CONTENIDO: Plan de pruebas general. Documentación sobre pruebas. Planes de prueba específicos.

Items a probar.Este plan de pruebas tiene como finalidad dictar los pasos a seguir para realizar un conjunto de pruebas sobre Delta Pensum 1.0 (reducido). Esta versión del sistema abarca los siguientes eventos del sistema:

Fase 1: Eventos básicos de Determinar Estado de Estudiante

*inicializar() *aprobar(id) *improbar(id) *aprobar(período) *improbar(período) *aprobarCréditos(bloque,cr) *improbarCréditos(bloque, cr) *cambiarANuevoPensum() *cambiarAViejoPensum() *despedirse()

Fase 2: Elaboración de una única recomendación

*iniciarRecomendación(inicio: Período) *desempatar(rompeEmpate: Elementos)

A esta reducción se llegó luego de hacer una replanificación del desarrollo para poder generar material de calidad en menor cantidad a lo esperado en un principio. A esta lista de eventos se debe añadir la correspondiente Interfaz que los soportará y el manejador de archivos que utiliza inicializar().Cabe destacar que por estas mismas restricciones de tiempo que tanto la cantidad y calidad de las pruebas a ser aplicadas pueden ser mermadas. Por lo tanto nos enfocaremos en tratar de conseguir un equilibrio entre el tiempo disponible y la cantidad de casos de prueba a aplicar. También debemos tener en cuenta cuáles son las partes de Delta Pensum ya codificadas que sean más propensas a tener errores y cuales son las pruebas más apropiadas para las mismas.

Características a ser probadas.Esperamos poder abarcar todas las partes de Delta Pensum desarrolladas en estas dos fases así como la interfaz y el manejo de archivos, elementos necesarios para poder hacer una entrega funcional del sistema. Cabe destacar que estas serán las primeras pruebas que se llevarán a cabo sobre este código, por lo tanto se espera que la aplicación de las mismas sea más complicado de lo normal.

Características que no se van a probarPor los momentos no se tiene contemplado retirar de las pruebas ninguna parte de Delta Pensum nombrada anteriormente. Pero esto está restringido al tiempo, por lo tanto de ser necesario se eliminarán algunas características de Delta Pensum del plan de pruebas.

1



ENFOQUE Este plan de pruebas se basará en su totalidad en pruebas del tipo Caja Negra. Entre las razones que se cuentan para tomar esta decisión esta la más importante: la restricción del tiempo, se sabe que las pruebas de caja blanca son más completas pero que necesitan mucho tiempo para poder ser llevadas a cabo; además las mismas se utilizan cuando se tiene todo el código desarrollado, lo cual no es este caso.Se considera como terminada una prueba cuando haya agotado su tiempo correspondiente, ese será el criterio de finalización a emplear.

CASOS DE PRUEBAMás adelante se mostrará el diseño de los diferentes tipos de prueba que serán aplicados así como los respectivos casos de prueba. Se emplearán pruebas:

Unitarias:MétodosClases

En las pruebas unitarias es donde se hará un mayor énfasis durante la fase de pruebas, en especial en las pruebas de métodos

Subsistemas Sistemas

El común se estas pruebas de sistema radica en que se tratará en lo posible de aprovechar los documentos de diseño generados en las fases anteriores del desarrollo: modelo use case, diagramas de colaboración, etc. para generar los casos de prueba que serán utilizados en el respectivo plan.

REQUERIMIENTOS y RECURSOS:Como no se cuentan con herramientas automatizadas las pruebas serán realizadas a “mano”. Se empleará como principal fuente de información el libro:

- Testing Object-Oriented Systems de Robert Binder.

Cada persona dispondrá de los recursos que considere necesarios y que pueda proveerse por si misma (máquinas, etc.)Tener instalado el JDK versión mayor o igual a 1.2.Tener en su classpath el archivo .tar de clases de Claire (para manejador de archivos).El hardware necesario para correr java (Pentium,16 MB, etc.)

TAREAS y RESPONSABILIDADESEl trabajo de pruebas se ha dividido en subgrupos de desarrolladores con la finalidad de que cada uno de ellos sea especialista en una fase del proceso de pruebas en específico. Cada subgrupo debe ser responsable de generar la siguiente documentación:

Marco Teórico sobre la respectiva pruebaConsiste en el soporte teórico del tipo de prueba. Tiene como finalidad servir de referencia rápida ante cualquier duda sobre el respectivo plan de prueba.

Plan de pruebaCasos de prueba como tal que corresponden al tipo de prueba desarrollado. Contiene todo lo necesario para poder generar el arnés de prueba y los respectivos casos.

2



Resultado de la pruebaLos desarrolladores al aplicar sus pruebas deben generar un documento en el cual muestren los casos de prueba realizados y los resultados obtenidos.Posteriormente queda por definir quienes serán los encargados de aplicar las pruebas al código. Se estudia la posibilidad de distribuir dicha responsabilidad de la misma forma en que se distribuyó la codificación: por diagramas de colaboración. Entonces cada persona debe chequear los planes de prueba generados y aplicarlos a sus diagramas de colaboración. Esto implica aplicar las pruebas de métodos a los métodos por él desarrollado y las clases en las que participa. Las secciones de Interfaz y manejo de archivos son responsabilidad de las personas que trabajaron en las mismas.

El Coordinador de Pruebas y sus asistentes serán los encargados de recoger toda la documentación generada, publicarla en la página Web de la Coordinación de Pruebas y supervisar que las pruebas se estén haciendo y la correctitud de las mismas.

Responsables de generar planes de prueba:

Pruebas de métodos Luis RojasPruebas de clases Julio RodríguezPruebas de subsistemas Carlos Ascanio y Javier BlancoPruebas de sistema Sory Gómez y Faustino Ubiaga

PLANIFICACIÓN:Semana 9 Pruebas Unitarias Fase 1

Pruebas Manejador ArchivosSemana 10 Pruebas Unitarias Fase 2

PRUEBAS FASE 1 COMPLETADASSemana 11 Pruebas Subsistema Fase 1 y 2

Pruebas InterfazPruebas de SistemaPRUEBAS FASE 2 COMPLETADAS

Semana 12 Actividades atrasadasInstalación de sistemaFINALIZACIÓN DE LAS PRUEBAS

RIESGOS:Cabe destacar que esta planificación prevé posibles atrasos, para lo cual se deja disponible la última semana, y la semana 10 que es bastante cómoda.Entre las posibles fuentes de problemas están:

Falta de tiempo: como se viene mencionando en este plan, el tiempo es la principal fuente de incertidumbre a la hora de aplicar las pruebas.

Plan de pruebas incorrecto: es posible que algún desarrollador realice mal su plan de pruebas, por lo tanto las pruebas que serán aplicadas serán defectuosas o incorrectas.

Mala interpretación: así como el plan puede estar malo, también es posible que los demás desarrolladores interpreten mal alguno de los contenidos del mismo y se apliquen mal las pruebas.

Atrasos en corrección de errores: se puede presentar el caso en el cual se descubran muchos errores y no haya tiempo de corregirlos, y menos tiempo habrá para seguir probando.

Atrasos en generación de casos de prueba.

3



APROBACIÓN:Plan a ser aprobado por Faustino Ubiaga N. y el Profesor Alejandro Teruel.

Plan de Pruebas de Métodos

CONTENIDOEn este documento, se va a presentar el conjunto de pruebas relacionado con los

métodos de Delta Pensum 1.0 en su primera implementación. Al ser este plan de pruebas el primero que se va a hacer de manera formal en la implementación del sistema, se puede decir que el código a probar está “crudo”. Esto se debe a que, aparte de las pruebas mínimas hechas por el programador, ninguno de estos métodos a sido probado con anterioridad.

Para poder probar los métodos del sistema, se va a hacer uso de las distintas herramientas suministradas por Binder en cuanto a UML, así como de ciertas revisiones basadas

4



en experiencias anteriores. Dado que las pruebas son de métodos por separados, se puede decir que las características a probar es la lógica del método por separado. Se dejará para otros planes de prueba el chequeo de la correctitud de métodos en casos mas complicados como en los que el funcionamiento depende de la relación con otros estados o cuando el método varía según el estado de la clase del método.

Este informe está basado en los distintos patrones de pruebas de métodos y en el análisis de fronteras que se pueden observar en el capítulo 10 de Binder.

En un principio, se espera que el plan de pruebas de métodos para Delta Pensum en su versión 1.0 conste de cuatro partes o categorías que se pueden diferenciar a través del tipo de métodos que se prueban. Estos tipos son:

Métodos triviales, o con poca necesidad de prueba. Métodos simples o que deben cumplir con cierto tipos de restricciones. Métodos polimorfos. Métodos complejos, los cuales son lo suficientemente complicados como para ser

tratados como subsistemas.

Nótese que a pesar de que Binder especifica otros dos tipos de métodos como los recursivos y los combinatorios, éstos no son tomados en cuenta debido a que estos tipos de métodos no se han identificado en el sistema Delta Pensum 1.0. En caso de hallar estos tipos de métodos, se procederán a desarrollar los casos de prueba tal como se especifica en el capítulo 10 del Binder.

ENFOQUE

Métodos Triviales

El primer tipo de métodos que vamos a examinar en este documento es el conjunto de métodos triviales. Este tipo de métodos no es señalado en el capítulo 10 del Binder, pero decidimos que se deben tomar en cuenta para reducir el número de casos de prueba del sistema.

Estos métodos están representados especialmente por aquellas funciones de creación y obtención-modificación de atributos privados de los distintos objetos del sistema. Ejemplo de estos métodos son:

modificarCodigo de la clase Encajable obtenerCodigo de la clase Encajable Constructores de clases Cualquier otro que agregue, modifique u obtenga de una clase un atributo sin hacer

chequeos.

Este tipo de métodos están caracterizados por simplemente poseer una línea de código en su cuerpo ya sea de retorno, o asignación. En caso de los constructores, el número de líneas de código puede ser mayor, pero de igual manera reducido y las operaciones son tan simples como llamar a un constructor y asignar valores a los atributos internos de la clase.

Para este tipo de método, dada su simplicidad, bastará con hacer una llamada al método para ver si está efectuándose correctamente la operación interna. Esto es suficiente gracias a que el método no hace ningún tipo de chequeo y que no posee acciones alternas (no posee condicionales).

Métodos simples.

5



Los métodos simples son aquellos métodos que no son lo suficientemente complejos como para ameritar un estudio exhaustivo de su correctitud, pero que posee ciertas variables interesantes y casos bordes que deben ser tomados en cuenta.

Entre estos métodos se encuentran las funciones de modificación de atributos y constructores que poseen un grado mas de complejidad con respecto a los métodos triviales ya sea debido a un chequeo o a la imposición de una frontera. Entre estos métodos también se encuentran lo métodos booleanos que indican el estado del objeto por medio de comparaciones. Como ejemplos de métodos no-triviales tenemos:

modificarNumero de la clase período (debe chequear que el nuevo numero sea menor que 16).

estaAprobado de la clase Bloque (verifica si el número de créditos aprobados es igual a el número total).

aprobarCreditos de la clase Bloque (ver que los créditos aprobados no sean mayores que 15).

aprobarEncajable de la clase Calendario Curricular (verificar que si es el último encajable de un período sin aprobar => el período también está aprobado.

Para este tipo de métodos, tenemos dos soluciones dependiendo de la complejidad de la función. En caso de que el método solo necesite hacer chequeos de frontera, entonces se deben crear dos caso de prueba para cada frontera: uno que este en la frontera y otro que esté fuera de la frontera en donde la ubicación del punto varía dependiendo de si la frontera es abierta o cerrada (ver Binder-estudio de fronteras para mayor información).

El segundo caso de métodos no-triviales está compuesto por los métodos simples pero que influyen en otros objetos como el caso de aprobarEncajable de la clase Calendario Curricular, en donde cambia el estado de un encajable y el del período si se cumplen ciertas condiciones.

Para este tipo de métodos se va a usar el patrón Categoría-Partición, de manera que se dividirán los casos de prueba por categoría generalizadas para no tener muchos casos para a continuación aplicar el estudio de fronteras.

Métodos polimorfos.

Los métodos polimorfos, siguiendo el concepto de Binder, son aquellos métodos que de una manera u otras lidian con instancias de objetos que pertenece a una de varias posibles clases debido a la aplicación de herencia en dichas instancias.

Como ejemplo de este tipo de métodos tenemos también al método aprobarEncajable de Calendario Curricular, el cual se comporta de manera distinta de acuerdo con el tipo de encajable que se está aprobando. Por ejemplo, la aprobación de un elemento genérico no solo se debe encargar de verificar el estado del período al que pertenece sino también al estado de su bloque respectivo, cosa que no se hace cuando se aprueba una asignatura.

En este caso se prosigue como indica Binder. Se hace la prueba para cada una de las posibles instancias que pueda tomar el objeto “multiple-instancia” en el método. En el caso de aprobarEncajable se prueba el caso de que el objeto sea una Asignatura, un Elemento Genérico y (si Encajable no fuera abstracto) un Encajable en si.

Otro tipo de polimorfismo que se presenta en Delta Pensum pero que no se considera en las pruebas de métodos planteadas en el capitulo 10 del Binder son los métodos sobre-escritos. La mayoría de estos métodos son sobre-escrituras hechas a métodos de clases nativas de Java como lo son el caso de obtenerEncajbles de la clase CatalogoEncajable, la cual es una sobre-escritura del método get de Hashtable. Estos métodos en parte son polimorfos por ser especializaciones de los nativos y por otro lado son polimorfos ya que hacen un “casting” de el objeto de clase Objeto al tipo que almacenan internamente.

6



Debido a que estos métodos son nativos de Java y al poco tiempo disponible par probarlos exhaustivamente, se decide tomar los métodos nativos como confiables y solamente se debe probar que el “casting” del objeto retornado sea correcto en caso de que el método devuelva algo, o probar que no se inserten objetos no deseados. Para cada uno de estos casos se debe hacer un caso de prueba.

Métodos complejos

Estos métodos abarcan aquellas funciones que son muy complicadas y que dependen de múltiples objetos y sus estados. Ejemplos de estos métodos son los ya archí conocidos: inicializar, cambiarPensumNuevo, iniciarRecomendacion y continuarRecomendacion.

Debido a la complejidad de estos métodos, en este informe se van a plantear las pruebas de métodos con valores muy subjetivos para los métodos complejos. Esto se debe a que en primer lugar, las salidas son muy complejas y la interacción del método con el sistema es muy complicada e interdependiente. Los resultados de estas pruebas pueden dejarse para ser vistos posteriormente a la hora de probar las clases y los subsistemas. El criterio a usar es el patrón Categoría-Transición.

Cabe destacar que a pesar de que estas pruebas planteadas pueden hallar una gran cantidad de fallas, todavía pueden hacerse gran cantidad de pruebas como los casos de Pruebas de Clases y de Jerarquía planteadas en Binder y otros casos que seguramente hallarán una mayor fuente de errores.

CASOS DE PRUEBADado a que para el momento en que se está escribiendo este informe no se han

terminado de identificar todos los métodos del sistema, todavía no se pueden dar todos los casos de prueba. Por este motivo, se indicará para cada tipo de método (trivial, simple, polimorfo y complejo) un caso ejemplo y se darán los casos de prueba respectivos.

Métodos Triviales

Como ejemplo de métodos triviales tenemos tres métodos relacionados de la clase Estudiante:

obtenerNombre() – retorna el nombre del estudiante. modificarNombre(String nom) – le asigna al estudiante el nombre nom. Estudiante(String nom, String c) – crea un nuevo estudiante con nombre nom y carnet c.

Obviamente se debe seguir el ciclo alfa-omega para poder hacer prueba de estos métodos y poder probarlos. Los valores de casos de prueba son los siguientes y se deben hacer seguidos:

MÉTODO VALORES DE PARAMETROS RESULTADO ESPERADOEstudiante Nom = “Luis”,

c = “94-26884”Ninguno

ObtenerNombre Ninguno “Luis”ModificarNombre Nom = “Rojas” NingunoObtenerNombre Ninguno “Rojas”

Similares casos de prueba se deben hacer para métodos triviales en todo el sistema Delta Pensum 1.0

7



Métodos SimplesComo ejemplo de método simple tomaremos:

ModificarNumero(int n) – (clase período) debe chequear que el nuevo numero del período sea menor que 16.

Como se indicó anteriormente, se deben cumplir ciertas condiciones en los métodos que entren en la categoría de simples, por lo que en algunos casos van a surgir excepciones. Actualmente, no están del todo definidas las excepciones en el sistema, así que bastará con indicar que se levantará una excepción cuando así se requiera y posteriormente (otros documentos), se indicará que tipo de excepción se levanta. Para verificar los resultados de estos métodos van a ser útiles los métodos triviales de obtención de datos (los cuales deben ser probados antes que los simples).

Casos de prueba para método modificarNumero:

VALOR DE PARAMETROS RESULTADO ESPERADO EXCEPCIÓNn = 15 Periodo.numero == 15 No se levantan = 16 Periodo.numero == 15 (no es

modificado) Se levanta

Anteriormente se consideraron métodos simples que son un poco mas complejos que aquellos en los que solo se deben considerar una frontera como el caso de aprobarEncajable. En este método, se debe considerar la aprobación de un encajable con distintas particiones de categoría tomando en cuenta el estado del sistema. En este caso la partición está dada por el estado del período en donde está el encajable.

Casos de prueba para aprobarEncajable(String cod)

Valor Parámetro Partición Resultado ExcepcionesCod / cod per Per no tiene

encajables aprobadosEl encajable cod está

aprobado Ninguna

Cod / cod per Per tiene un encajable ( cod) aprobado

El encajable cod está aprobado Ninguna

Cod / cod per Per tiene todos sus encajables aprobados Ninguno Ninguna

Cod / cod per Per cualquiera Ninguno Se levanta

Métodos Polimorfos

Uno de los métodos polimorfos que destaca mas en el sistema es aprobarEncajable(String cod) de la clase CalendarioCurricular. En este caso, el polimorfismo radica en que el encajable a aprobar puede ser un elemento genérico o una asignatura; y de acuerdo con la clase del encajable varía el método.

Valor de parámetros Clase encajable Resultados Excepciones

“EG-1” Elemento GenéricoSe aumenta los

créditos aprobados en el período.

Ninguna

“CI-2831” Asignatura

Se aumenta los créditos aprobados

en el período.Se aumenta los

créditos aprobados en bloque.

Ninguna

Cualquiera (CI-2121) Encajable Ninguno. Excepción: Encajable es abstracta

8



Métodos Complejos

Como ejemplo tendríamos en iniciarRecomandación, el iniciarla con un calendario totalmente aprobado, uno sin nada aprobado, uno con problemas de oferta y uno con errores en caso de ser posible para observar como reacciona el método. Estas particiones pueden ser tan generalizadas como se puedan ocurrir, ya que debido a la complejidad del subsistema genera una cantidad de casos de prueba infinita.

Nótese que debido a la complejidad de este método, los valores son muy generalizados y subjetivos. Para hacer un estudio mas profundo se deben hacer pruebas de clase y de subsistema a este método.

Parámetros Resultado esperadoCalendario sin materias aprobadas Recomendación curricular idéntica al calendario

curricular.Calendario con todas las materias aprobadas Recomendación curricular vacíaCalendario con todas las materias hasta el i-

ésimo trimestre aprobadas.Complemento del calendario curricular (a partir del

trimestre i-ésimo).Calendario Problemático Devuelve consulta para el usuario con un empate

constantemente.Calendario no al día Devuelve consulta para el usuario con un empate

Tanto los calendarios problemáticos (no cumplen requisitos, rebuscados) como los que no están al día (típicos) pueden comprender un conjunto muy grande de combinaciones, cada una con un resultado diferente y que posiblemente no sea el mas óptimo. Así que en la mayoría de los casos se va a tener que hacer un chequeo mas intensivo en este tipo de métodos.

También es deseable en este tipo de pruebas tener unos cuantos casos que según el encargado de pruebas puedan ser rebuscados. En otras palabras, implementar casos de prueba maliciosos.

TAREASPara la aplicación de este plan de pruebas se pueden observar las siguientes tareas a

tomar en cuenta:

Creación de código con la posibilidad de que este sea compilado. División de todos los métodos del sistema según las 4 categorías (triviales, simples,

polimorfos y complejos). Generar y probar los casos de prueba de los métodos triviales hasta que se satisfagan

los resultados esperados. Generar y probar los casos de prueba de los métodos simples hasta que se satisfagan los

resultados esperados. Generar y probar los casos de prueba de los métodos polimorfos hasta que se satisfagan

los resultados esperados. Generar y probar los casos de prueba de los métodos complejos hasta que se satisfagan

los resultados esperados siempre y cuando la complejidad y grado de abstracción del caso de prueba lo permita.

REQUERIMIENTOS DE AMBIENTELas personas que vayan a probar los métodos del sistema deben tener los siguientes

elementos en su ambiente: Cualquier plataforma o sistema operativo (gracias a java). Tener instalado el JDK versión mayor o igual a 1.2.

9



Tener en su classpath el archivo .tar de clases de Claire (para manejador de archivos). El hardware necesario para correr java (Pentium,16 Mb, etc.)

RESPONSABILIDADESLa distribución de pruebas del sistema DP 1.0 va a ser hecha según los desarrolladores

del método a probar. Cada uno de los programadores va a tomar sus métodos y va a efectuar las 6 tareas para las pruebas para finalmente darle tanto los casos de prueba, como los resultados esperados y los obtenidos.

PERSONAL NECESARIO Y ENTRENAMIENTOPara poder hacer las pruebas, dado que el encargado de dicha actividad es el mismo

desarrollador, no es necesario ninguna destreza que ya no posea un programador en el lenguaje Java. También es necesario estar acostumbrado a el chequeo de fronteras como se explica en el capitulo 10 del Binder.

RIESGOS Y CONTINGENCIASSe asume que el programador del código va estar disponible para poder hacer las

pruebas de su código. En caso de que este no sea el caso, otro desarrollador o el coordinador de pruebas debe asumir el papel de implementador de pruebas.

El mayor riego es el tiempo. Dado a que se dispone de muy poco tiempo para terminar el sistema, lo mas probable es que el tiempo sea muy escaso como para hacer las pruebas necesarias. En este caso se harén las pruebas mas importantes como lo son lo métodos complejos y simples.

No se están considerando métodos recursivos ni combinatorios. En caso de que estos surjan se debe hacer un nuevo estudio de pruebas tomando en cuenta lo que Binder dice al respecto.

Otro riesgo que puede afectar notablemente las pruebas es que los métodos no estén definidos por completo para poder diseñar un plan de pruebas completo. Es por esto que cada programador está encargado de probar su propio cogido.

Finalmente, dado que no hay tiempo para generar código de prueba como drivers y stubs, se tratarán de hacer las pruebas en orden top-down para evitar el uso de métodos erróneos.

APROBACIÓNLos encargados tanto de la revisión como de la aprobación de los casos de prueba en el

plan son:

Luis Rojas (especialista en pruebas de métodos).Faustino Ubiaga (coordinador de pruebas).

10



Plan de Pruebas de ClasesSe realizaran pruebas básicas sobre todas las clases que integran el sistema de Delta

Pensum 1.0 .

El motivo de hacer las pruebas mínimas es porque no se dispone de mucho tiempo para la implementación quedando de esta forma muy poco tiempo para las pruebas de sistemas.

Se harán pruebas sobre las invariantes de clases almacenando en una matriz de pruebas de dominios los valores seleccionados y verificando a través de los métodos que proporciona la clase si los valores son aceptados o no.

Para poder realizar las pruebas se debe:1. Tomar las invariantes de la clase.2. Tomar los Fronteras de las invariantes (puntos “sobre” y “fuera”), estos son los

valores críticos y sobre los cuales se basaran las pruebas.3. Se debe crear una matriz de pruebas. Donde se indique los puntos, así como también

los algunos puntos dentro de los limites (estos puntos deben ser tomados al azar preferiblemente).

4. Cada columna de la matriz indica una prueba.5. Si una prueba no pasa, se debe corregir el error y volver a correr el patrón de nuevo

puesto que se pudo haber modificado otras secciones del programa.

Ejemplo:Prueba sobre la clase Encajable:Las invariantes de esta clase son:

1. Codigo, debe ser alguno de los códigos válidos designados para las asignaturas.2. nombre, (String) debe corresponder al código de la asignatura.3. abreviación, (String) debe corresponder al código de la asignatura.4. estado , (Char) debe pertenecer a (v,e,n,s).5. solitaria ,(Bolean) debe ser verdadero o falso.6. encajado ,(Bolean) debe ser verdadero o falso.6. creditos, (Integer) debe estar en un rango de 1..16.

11



Variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14Codigo On ci-

4712Off Ci8888

Nombre On Ing. Del Software II

off Medicina

Abreviación On Ing II

Off MedEstado On s

Off oSolitaria On tru

eOff fals

eEncajado On Fals

eOff true

Creditos On 4Off 17

La prueba de clase que acabamos de ver tiene 14 sub-pruebas.Las pruebas de las clases deberían hacerse todas de igual manera.

12



PLAN DE PRUEBAS DE SUBSISTEMAS

CONTENIDOEn este documento, se va a presentar el conjunto de pruebas relacionado con los

subsistemas de Delta Pensum 1.0 en su primera implementación. La importancia de este plan de pruebas es que será llevado a cabo sobre los métodos y clases ya probados, en este momento es que las funcionalidades separadas del sistema comenzaran a probarse.

Para probar los subsistemas de Delta Pensum 1.0, se va a hacer uso de las herramientas suministradas por Binder. Dado que las pruebas se realizaran a subsistemas separados, pero no disjuntos, nos darán un enfoque del funcionamiento del sistema por partes, esto no significa que el comportamiento del sistema completo sea correcto. Se dejará para otro plan de pruebas el chequeo de la integración de estos subsistemas.

Este informe está basado en los distintos patrones de pruebas de subsistemas que se pueden observar en el capítulo 12 de Binder.

ENFOQUEBinder nos ofrece en el capítulo 12 cuatro patrones para diseño de pruebas de

subsistemas, las cuales nos presentan distintas estrategias para probar diferentes funcionalidades en estos. Estas se describen a continuación.

Pruebas de Asociación de Clases

Nos permite diseñar planes de prueba que ejerciten las asociaciones entre las clases de cada subsistema.

Si van a ser usadas de la forma como se describe posteriormente. Pruebas de Control de Excepciones

Permite diseñar planes de prueba que ejerciten el manejo de excepciones.

No van a ser usadas en el ámbito de subsistemas, porque se contemplaron para ser realizadas en las pruebas de clases. Pruebas de Escenarios de Ida y Vuelta

Permite diseñar un plan de pruebas que cubra todos los caminos evento-respuesta en un diagrama de secuencia.

Si van a ser usadas, y la forma de ejercitarlas se describe posteriormente.

Pruebas de Modelo de Máquinas

Nos permite modelar el comportamiento de los estados de un conjunto de clases y desarrollar un plan de pruebas basado en estados.

No lo vamos a usar porque involucran el uso de máquinas de estado, acerca de las cuales se dijo anteriormente la razón por la cual no se iban a usar.

CASOS DE PRUEBA

13



También es deseable en este tipo de pruebas tener unos cuantos casos que según el encargado de pruebas puedan ser rebuscados. En otras palabras, implementar casos de prueba maliciosos.

Pruebas de Asociación de Clases

Las pruebas de asociación de clases nos brindarán una herramienta muy útil para encontrar esencialmente tres tipos de fallas:

Multiplicidad incorrecta.Anomalías en las actualizaciones. Anomalías en los enlaces y errores en la exclusión mutua (si existe).

Antes de comenzar las pruebas a un subsistema, todas las clases que lo componen deben haber sido probadas rigurosamente mediante el ciclo Alfa-omega e individualmente con pruebas de clases Quasi-modales.

También sería deseable poder probar el subsistema haciendo uso de la interfaz gráfica.

La primera prueba que debe ser elaborada en el subsistema, es la de las posibles instancias erróneas.Para esto, se debe elaborar una tabla que contenga las posibles instancias (o las más críticas) de asociaciones entre pares de clases del subsistema. Número de Instancias de un período que contiene instancia(s) de encajables

Número de instancias de encajables que son contenidos por un período

Período contiene 0..N encajable(s)

Encajables contenidos por 1..N períodos

0 Ninguna relación período-encajable se representa en el sistema

01*N

OKOKOKOK

OKCORRUPTOCORRUPTOCORRUPTO

1Al menos una relación período-encajable se repre-senta en el sistema

01*N

OKOKOKOK

OKOKOKOK

NMuchos relaciones perído-encajable se representan en el sistema

01*N

OKOKOKOK

OKOK(2)/CORRUPTOCORRUPTOCORRUPTO

Un encajable no puede ser compartido por dos o más períodos del mismo pensum, y máximo por dos períodos de pensums diferentes, tal como se puede observar en el cuadro anterior.

Para tener un control del número de instancias permitidas en la asociación entre dos clases, se debe construir la tabla de condiciones de borde para multiplicidades legales.

Multiplicidad de Período a Encajable

Condiciones de Borde

* Período:n(Encajable)>=0 Período:n(Encajable)<=N0 Período:n(Encajable)=01 Período:n(Encajable)>=0 Período:n(Encajable)<=8...

14



La notación Período: n(Encajable) >= 0, traduce: “Para cada instancia de período, el número de encajables debe ser mayor o igual a cero”.

Una vez definidos las condiciones de borde de las asociaciones en ambos sentidos, se procede a elaborar la tabla de casos de prueba:

Variable/Cond/Tipo

Casos de Prueba1 2 3 4 5 8

NúmeroDeEncajables

Per:n(Enc)>=0

ON 0OFF -1

Per:n(Enc)<=8

ON 8OFF 9

Típico EN 4 4NúmeroDePeríodos

Enc:n(Per)>=0

ON 0OFF

Enc:n(Per)<=2

ONOFF 3

Típico EN 1 1 1 1Resultado Esperado X X X

Con el uso de esta tabla, se determina el dominio del subsistema.

Pruebas en Escenarios de Caminos Ida y Vuelta (Round Trip)

Al igual que en el modelo de pruebas anterior, para llevar a cabo las pruebas generadas por esta estrategia, se tiene como un hecho que ya han sido probadas individualmente las clases participantes en el subsistema que se esté probando con esta estrategia; y además de esto debería poderse realizar las pruebas utilizando la interfaz gráfica.

Este tipo de pruebas nos brinda las herramientas para encontrar los siguientes tipos de fallas:

Disparar o Manejar incorrectamente una excepciónPerder un Mensaje o enviar uno incorrectoPerder o Errar una GuardiaOlvidar Asignar un resultadoIndicar un parámetro erradoEnviar el Mensaje correcto pero al Objeto equivocadoEquivocar una Secuencia de mensajesCrear ciclos incorrectos

Todas estas fallas se traducen en un desempeño inadecuado del subsistema, por lo que pondrían en juego la finalidad del sistema entero.

La estrategia de Round Trip se basa en generar pruebas a través del análisis de los Diagramas de Colaboración, y consta de cuatro pasos:

Traducir los Diagramas de Colaboración en Diagramas de FlujoIdentificar en estos, el tipo de cobertura y los caminos a probarAplicar Subestrategias para lograr la cobertura deseadaIdentificar casos especiales

15



Dado el corto tiempo que se tiene y el poco manejo de Diagramas de Flujo, los Diagramas de Colaboración no serán traducidos, sino que se trabajará sobre ellos mismos con los pasos dos, tres y cuatro.

Para generar este tipo pruebas, lo primero que vamos a hacer es identificar los subsistemas presentes, luego, para cada uno de ellos se identificarán los diagramas de colaboración envueltos en el subsistema a probar.

Una vez que se tengan los diagramas (que en algunos casos puede ser un solo diagrama) se identificarán todos los posibles caminos que pueden encontrarse, y para cada camino, se verificará si da muestras de alguna de las fallas antes mencionadas.

Caminos encontrados en el diagrama Aprobar Período

1.Despachador llama a Pensum con AprobarPeríodo.2.Despachador llama a Pensum y este a Calendario Curricular con AprobarPeríodo3.Despachador llama a Pensum, este a Calendario Curricular y este al Catalogo Período Encajable con ObtenerPeríodo.4.Despachador llama a Pensum, este a calendario Curricular, este a Catalogo Período Encajable, y este a Período con AprobarDirecto5. Despachador llama a Pensum, este a calendario Curricular, este a Catalogo Período Encajable, este a Período, y este a Catalogo Período Encajable con ObtenerEncajable.6. Despachador llama a Pensum, este a calendario Curricular, este a Catalogo Período Encajable, este a Período, este a Calendario Curricular, este a Catalogo Período Encajable, y este último a Encajable con AprobarDirecto.

Luego de haber conseguido todos los caminos (en este caso los 6 antes descritos), se obtendría una tabla como la siguiente, en la cual se trabaja con el período 4 del pensum viejo, y en la cual el estado inicial tanto del mismo como de los encajables pertenecientes a dicho período es sin aprobar.

Camino Periodo Estado Encajables Estado1 4 Sin aprobar Todos Sin aprobar2 4 Sin probar Todos Sin aprobar3 4 Sin aprobar Todos Sin aprobar4 4 Sin aprobar Todos Sin aprobar5 4 Sin aprobar Todos Sin aprobar6 4 Sin aprobar Todos Sin aprobar

Después de las llamadas de los métodos de cada camino, la tabla debería lucir como sigue:

Camino Periodo Estado Encajables Estado1 4 Sin aprobar Todos Sin aprobar2 4 Sin probar Todos Sin aprobar3 4 Sin aprobar Todos Sin aprobar4 4 Aprobado Todos Sin aprobar5 4 Aprobado Todos Sin aprobar6 4 Aprobado Todos Aprobado

Y además, las siguientes salidas para cada uno de estos métodos:

16



Método Clase SalidaAprobarPeríodo() Pensum NingunaAprobarPeríodo() Calendario Curricular Ninguna. Se incrementan los

créditos aprobados de este período, y se aprueban sus encajables, pero después de que se ha recorrido el camino 6.

ObtenerPeríodo(codigoperiodo) Catalogo periodo encajable Periodo 4AprobarDirecto(codigoperiodo) Período Se aprueba el período.ObtenerEncajables(4) Catalogo periodo encajable Lógica Algoritmos I Discretas I

Matemáticas IVAprobarDirecto(encajable) Encajable Esto se hace para cada

encajable, y su estado cambia a aprobadopensumviejo.

Un estado corrupto en el subsistema sería el siguiente:

Camino Periodo Estado Encajables Estado1 4 Sin aprobar Todos Sin aprobar2 4 Sin probar Todos Sin aprobar3 4 Sin aprobar Todos Sin aprobar4 4 Sin aprobar Todos Sin aprobar5 4 Sin aprobar Todos Sin aprobar6 4 Sin aprobar Todos Aprobado

Junto con una tabla de salidas para los métodos como la siguiente:

Método Clase SalidaAprobarPeríodo() Pensum NingunaAprobarPeríodo() Calendario Curricular Ninguna. Se incrementan los

créditos aprobados de este período, y se aprueban sus encajables, pero después de que se ha recorrido el camino 6.

ObtenerPeríodo(codigoperiodo) Catalogo periodo encajable Periodo 4AprobarDirecto(codigoperiodo) Período No se aprueba el período.ObtenerEncajables(4) Catalogo periodo encajable Lógica Algoritmos I Discretas I

Matemáticas IVAprobarDirecto(encajable) Encajable Esto se hace para cada

encajable, y su estado cambia a aprobadopensumviejo.

Utilizado estas tablas, se probaran los subsistemas, comparando los resultados obtenidos contra los de la tabla, y realizando los ajustes necesarios para arreglar cada error encontrado.

El caso de prueba a realizar debe ser presentado como sigue:

Caso de Prueba Resultados EsperadosInvocación al método aprobarperíodo del El período “4” cambia su estado a “Aprobado”,

17



período 4 el número de créditos aprobados en este período es el número total de estos que lo conforma, los encajables pertenecientes a este período cambian su estado a “Aprobado”.

REQUERIMIENTOS DE AMBIENTEPara realizar las pruebas es necesario usar el siguiente ambiente de trabajo:

Cualquier plataforma o sistema operativo. JDK versión mayor o igual a 1.2. El hardware requerido por la máquina virtual de java.

RESPONSABILIDADESLos desarrolladores estarán encargados de hacer las pruebas de los subsistemas

relacionados con su diagrama de colaboración, teniendo cuidado de no hacer pruebas sobre un mismo subsistema. Este problema será resuelto, asignando las pruebas en una reunión del equipo y revisando constantemente el control de versiones de las clases involucradas de manera tal que siempre se trabaje con la versión actualizada.

Los desarrolladores efectuarán las tareas de las pruebas para generar un informe con los casos de prueba, los resultados esperados y los resultados obtenidos.

PERSONAL NECESARIO Y ENTRENAMIENTOPara poder hacer las pruebas, dado que el encargado de dicha actividad es el mismo

desarrollador, no es necesario ninguna destreza que ya no posea un programador en el lenguaje Java.

RIESGOS Y CONTINGENCIASSe asume que el programador del código va estar disponible para poder hacer las

pruebas de su código. En caso de que este no sea el caso, otro desarrollador o el coordinador de pruebas debe asumir el papel de implementador de pruebas.

El mayor riego es el tiempo. Dado a que se dispone de muy poco tiempo para terminar el sistema, lo más probable es que el tiempo sea muy escaso como para hacer todos los casos de pruebas generados.

Escoger bien los subsistemas y delimitar correctamente sus fronteras puede ser otro riesgo que puede afectar notablemente las pruebas. Un subsistema mal delimitado podría perder parte de la funcionalidad requerida o tener parte en otro subsistema, además, podrían generarse muchos casos de prueba innecesarios.

Es muy importante que se respete el control de versiones. Cualquier cambio a una clase debe ser reportado de inmediato. Varias versiones circulando al mismo tiempo pueden ser causa de errores ocultos en el sistema terminado.

La deshonestidad de los desarrolladores a la hora de hacer pruebas y generar reportes puede llegar a ser un terrible problema de enormes e indescifrables magnitudes para el sistema.

APROBACIÓN

18



Los encargados tanto de la revisión como de la aprobación de los casos de prueba en el plan son:

Carlos Ascanio y Javier Blanco (especialistas en pruebas de subsistemas).Faustino Ubiaga (coordinador de pruebas).

Plan de Prueba de Sistemas

CONTENIDOEste documento está compuesto por el patrón que se va a seguir para realizar las

pruebas en el ámbito de sistemas de Delta Pensum.Para la elaboración de este plan de pruebas se siguieron las recomendaciones hechas

por el Profesor Alejandro Teruel, el capítulo 14 del Testing Object Oriented Systems de Binder y el plan de incremento realizado en la fase de análisis de requerimientos Este plan esta divido en tres grandes partes:

Capacidades del sistema, basado en el plan de incrementos. Aspectos especiales de Delta Pensum. Casos de Uso Extendidos.

ENFOQUEProbar una aplicación al nivel de sistema tiene como finalidad conseguir errores que solo

pueden presentarse a este nivel, demostrar que se cumplen todos los requerimientos e indicar si es posible hacer un release de la aplicación.

Siguiendo estos objetivos podemos concentrar nuestros esfuerzos en dividir las pruebas en las tres partes antes nombradas. Los casos de uso extendidos tienen como finalidad

19



demostrar que la funcionalidad esperada es cumplida y las capacidades del sistema busca que los requerimientos funcionales sean cumplidos de la manera esperada. Ambos aspectos fueron trazados al principio del desarrollo como requerimientos del sistema, tanto funcionales como no funcionales, dentro del plan de incremento,

Son estos los aspectos que deben ser probados principalmente a este nivel. Para ello empleamos el patrón de casos de uso extendido. Al final del documento se pueden observar los casos de prueba generados según este patrón. Dichos pruebas deben ser realizadas y reportadas.

En lo que respecta a las capacidades del sistema a continuación vamos a mostrar cuáles son estos aspectos a tomar en cuenta.

Capacidades del sistema, basado en el plan de incrementos.

Las funciones que desempeñará Delta Pensum

1. Determinar el estado del estudiante en un pensum viejo de estudios2. Determinar a partir de las asignaturas que el usuario haya indicado como aprobadas en

un pensum viejo y las equivalencias de asignaturas entre un pensum viejo y uno nuevo, el estado de las asignaturas en un pensum nuevo (aprobado/por cursar). 3. Mostrar en pantalla con un formato agradable cualquier LA y NLA. En este formato no solo se deben indicar las signaturas aprobadas, sino también aquellas que faltan por cursar con respecto al Pensum indicado.

3. Determinar el plan de estudios trimestral del estudiante, PET. Para cada trimestre se indicará qué asignaturas se le recomienda cursar para graduarse en un tiempo mínimo respetando la oferta trimestral de asignaturas, los requisitos de las asignaturas y el número máximo de créditos cursables por trimestre (fijo en 16 para Delta Pensum 0). Una oferta puede ser regular o de transición. Delta Pensum 0 sólo funciona correctamente para elaborar un plan de estudios cuyo primer trimestre corresponda a Verano 1999 o Setiembre-Diciembre 1999.

4. Leer los datos que definen los Pensum, las ofertas y las equivalencias de archivos.

Los atributos del sistema

Se pueden clasificar en los siguientes aspectos (apoyados en el análisis de requerimientos):

1. Configuración y compatibilidad:El sistema debe ser capaz de correr bajo ambiente Windows 95-98-NT, Linux y Solaris. Pero se considera imprescindible que pueda ser montado en las máquinas del Profesor Teruel (Solaris) y de la Coordinadora de la Carrera (Windows NT). Para ello se debe chequear que en ambas máquinas no se tengan problemas de instalación y de requerimientos de hardware. Se debe garantizar el JRE (al menos) para poder ejecutar código de java en las respectivas máquinas. Para más detalles ver manual de instalación.

2. PerformanceDurante el análisis de requerimientos se hicieron algunas observaciones sobre el desempeño del sistema que no deben ser olvidadas:

El acto de activar componentes gráficos no debe generar un tiempo de respuesta perceptible para el usuario.

Al introducir texto en sus respectivos campos no se debe tomarse más de 2 segundos en responder.

Un cambio de Pensum no debe tomarse más de 30 segundos.Una recomendación sin desempates debe tomarse como máximo 30 segundos.

3. Tolerancia a fallas

20



En aspecto no existe mucha rigurosidad, así que con tumbar el sistema en medio de su ejecución y volver a montarlo no debería generar problemas, tales como: corrupción de archivos, variables mal inicializadas, etc.

4. Interacción Humano – ComputadoraSe deben cumplir las expectativas en lo que se refiere a la interfaz. Para ello se debe pedir opinión a personas que estén fuera del equipo de desarrollo y especialmente al usuario (Coordinadora y asistente).

a. La interfaz debe ser gráfica y agradable a la vista.

b. En prototipos previos se determinó que la parte más tediosa es la introducción manual de las asignaturas aprobadas. Para evitar esto, de desea que se puedan introducir dichos datos de forma abreviada usando el ratón, de manera que con un clic se puedan escoger materias individuales o todas las materias de un período académico (año, trimestre). Con igual facilidad se deben deseleccionar dichas materias. También se debe chequear los aspectos configurables de la interfaz.En este mismo ámbito deben ser chequeado los manuales, y en general toda la documentación que pueda ser usada por el usuario.

Aspectos especiales de Delta Pensum.

Existen muchos aspectos del sistema Delta Pensum, propios del mismo, que pueden ser fuente de errores a nivel de sistema, entre estos tenemos los siguientes que deben ser tomados en cuenta para realizar las pruebas:

Chequear que pasa cuando tenemos una recomendación con más de 15 trimestres, posibles problemas de interfaz y codificación.

Chequear, en la medida de lo posible, la validez de la heurística, posibles problemas de diseño y codificación.

Manejo de las asignaturas sobrantes al equivaler Pensum, problemas de interfaz. Manejo de las asignaturas aprobadas sin un requisito, problemas de interfaz y

manejo de las prelaciones. Chequeo de la completitud y correctitud de los datos almacenados en los archivos

del sistema: Pensum viejo, nuevo, oferta y equivalencias, posibles problemas con inicializar e interfaz.

#REF Función Atributo Detalles Cat./ Cumplido

R1.1

Determinar estado con introducción interactiva de datos

Tiempo respuesta

Menos de dos segundos para cambiar el estado de una asignatura que ha sido seleccionada

Deseable/SI

Interfaz Amistosa Deseable/SI

R2Equivalencia de asignaturas en nuevo Pensum

Tiempo respuesta

Menos de 30 segundos Deseable/SI

InterfazReportar equivalencias precisa y claramente

Imprescindible/SI

R3Determinación de Plan de estudios

Tiempo respuesta

Menos de 30 segundos deseable/NO

21



InterfazReportar clara y precisamente

imprescindible/NO

R5Mostrar estado en un Pensum o un plan de estudios

InterfazRotular claramente según caso

imprescindible/NO

TAREASPara la aplicación de este plan de pruebas se pueden observar las siguientes tareas a

tomar en cuenta:

La codificación de Delta Pensum debe estar completamente terminada, con pruebas unitarias y pruebas de subsistema completadas.

REQUERIMIENTOS DE AMBIENTE Y SISTEMAPara poder probar el sistema es necesario lo siguiente:

Cualquier plataforma o sistema operativo (gracias a java). Tener instalado el JDK versión mayor o igual a 1.2. Tener en su classpath el archivo .tar de clases de Claire (para manejador de archivos). El hardware necesario para correr java (Pentium,16 Mb, etc.)

Y en lo que respecta al sistema es necesario: Paquete deltapensum Paquete interfaz Imágenes necesarias Archivos de Pensum viejo, nuevo, oferta y equivalencias.

RESPONSABILIDADESEl encargado de ejecutar las pruebas de sistema es el Coordinador de Pruebas

PERSONAL NECESARIO Y ENTRENAMIENTOCoordinador de Pruebas.

RIESGOS Y CONTINGENCIASEl mayor riego es el tiempo. Dado a que se dispone de muy poco tiempo para terminar el

sistema, lo mas probable es que el tiempo sea muy escaso como para hacer las pruebas necesarias. En este caso se harán las pruebas suficientes para probar la funcionalidad deseada del sistema y que los requerimientos no funcionales mínimos se cumplan.

No se hayan terminado satisfactoriamente alguna de las condiciones necesarias para ejecutar este tipo de pruebas:

Finalización de la codificación.Finalización de las pruebas unitarias.Finalización de las pruebas de subsistemas.

APROBACIÓNLos encargados tanto de la revisión como de la aprobación de los casos de prueba en el

plan son:Sory Gómez (especialista en pruebas de casos de uso extendidos)Faustino Ubiaga (coordinador de pruebas)

22



23



EXTENSIÓN DE LOS CASOS DE USOCaso de Uso Elaborar Recomendación Curricular

Variable Clasificación Dominio Tipo

Carnet del estudiante EntradaFormato: xx-xxxxx / x: 0-9.Puede ser nulo.

Entero

Nombre del estudiante EntradaCualquier String es válido. Puede ser nulo. String

Pensum de preferencia Ambiente Distinto de nulo y vacío. PensumCalendario Curricular de preferencia Ambiente Distinto de nulo y vacío. CalendarioCurricularPeriodo de Inicio Entrada 1..15 EnteroPeriodo de Inicio de Preferencia Ambiente 1..15 Entero

Calendario Curricular Actual AmbienteCorrespondiente al pensum nuevo.Distinto de nulo.

CalendarioCurricular

Recomendación Curricular SalidaDistinto de nulo.Sus valores son consistentes entre sí Recomendación Curricular

Lista de Encajables Empatados Entrada/Salida

Cada elemento en el conjunto corresponden con encajables que:

- No han sido encajados.- Tienen sus prelaciones

satisfechas.- Están ofertados en el

trimestre

Conjunto donde cada elemento contiene:- Nombre del encajable.- Código del encajable.- Creditaje del encajable.

Lista de Encajables Desempatados Entrada/Salida Cada elemento en el conjunto corresponden con encajables que:- No han sido encajados.- Tienen sus prelaciones

Conjunto donde cada elemento contiene:- Nombre del encajable.- Código del encajable.- Creditaje del encajable.

24



satisfechas.- Están ofertados en el

trimestreLa suma del creditaje de los encajables debe ser menor o igual a 16 créditos.

Nombre del documento Entrada/Salida

El nombre del documento no debe excederse de 7 caracteres y solo puede constar de números y/o letras. Puede ser nulo

String

Localidad del documento Entrada/Salida

Debe ser un camino de archivo valido para DOS. Cada uno de los directorios dentro del camino debe existir y respetar la jerarquía expuesta en el camino.Puede ser nulo.

String

Nombre del documento de preferencia Entrada/SalidaEl nombre del documento no debe excederse de 7 caracteres y solo puede constar de números y/o letras.

String

Localidad del documento de preferencia Entrada/Salida

Debe ser un camino de archivo valido para DOS. Cada uno de los directorios dentro del camino debe existir y respetar la jerarquía expuesta en el camino.

String

Elementos Extra-Pensum Entrada/Salida

Cada elemento consta de:- Código del encajable.- Nombre del encajable- Abreviación del encajable.- Número de créditos

(opcional)

Elementos Extra-Pensum

Observaciones Entrada/Salida Cualquier cadena de caracteres es válida. String

Elementos Extra-Curriculares Entrada/Salida

Cada elemento consta de:- Código del encajable.- Nombre del encajable- Abreviación del encajable.- Número de créditos

(opcional)

Elementos Extra-Curriculares

25



RAM Salida

Debe contener: - Versión del programa.- Fecha de los archivos sobre

los cuales se apoya un documento.

RAM

Como son muchas las variables operacionales se va dividir los casos de usos por componentes.

A continuación se presentarán las relaciones operacionales para cada uno de estos componentes.

Relaciones operacionales para componente 1:Componente 1:

Items:1,2,3,4 Alternativas:1,4,6

Variables Operacionales Respuesta del sistemaVariante Carnet del

Estudiante Nombre del Estudiante

1 Invalido DC Muestra un mensaje de error, indicando que el valor del carnet es erróneo. Luego se espera por un nuevo valor de Carnet y nombre del estudiante.

26



2 Valido DC Se muestra el Calendario Curricular de Preferencia correspondiente al Pensum de Preferencia.

3 DC DC

Cuando el Coordinador solicita comenzar la consulta de otro estudiante, el sistema advierte que borrará todos los datos introducidos por el Coordinador (salvo los cambios de preferencia) o calculados por el sistema. De confirmar el Coordinador la solicitud, el sistema solicita nombre y carnet del estudiante. (Se devuelve al item 2 del caso de uso Elaborar Recomendación Curricular).

Relaciones operacionales para el componente 2:Componente 2:

Items:6, 7, 8, 9, 10 Alternativas:2, 4, 6, 8, 9, 10

Variables Operacionales Respuesta del Sistema

Variante

Periodo de Inicio

Periodo de Inicio de Preferencia

Calendario Curricular Actual

Recomendación Curricular

Lista de Encajables Empatados

Lista de Encajables Desempatados

Calendario Curricular Paralelo

1 Valido DC Válido Válido Válido Válido Válido Se muestra una Recomendación Curricular Completa.

27



2 Invalido DC DC DC DC DC DC Se muestra un mensaje de error y se solicita un nuevo valor de Periodo de Inicio.

3 Nulo Válido Válido Válido Válido Válido Válido Se muestra una Recomendación Curricular Completa.

4 Nulo Inválido DC DC DC DC DC Se muestra un mensaje de error y se solicita un nuevo valor de Periodo de Inicio.

5 Nulo Válido Inválido DC DC DC DC Se muestra un mensaje de error y se solicita el cambio a Pensum Nuevo.

6 Nulo Válido Válido Inválido DC DC DCSe muestra un mensaje de error indicando la inconsistencia de la Recomendación Curricular.

7 Nulo Válido Válido Válido Inválido DC DC Se muestra un mensaje de error indicando que la Lista de Encajables es inválida.

8 Nulo Válido Válido Válido Válido Inválido DCSe muestra un mensaje indicando que esa Lista es inválida y se le permite al usuario elegir un nuevo conjunto de encajables.

9 Válido DC Inválido DC DC DC DCSe muestra un mensaje de error y se solicita el cambio a Pensum Nuevo.

10 Válido DC Válido Inválido DC DC DCSe muestra un mensaje de error indicando la inconsistencia de la Recomendación Curricular.

11 Válido DC Válido Válido Inválido DC DCSe muestra un mensaje de error indicando que la Lista de Encajables es inválida.

12 Válido DC Válido Válido Válido Inválido DC

Se muestra un mensaje indicando que esa Lista de Encajables Desempatados es inválida y se le permite al usuario elegir un nuevo conjunto de encajables.

13 Valido DC Válido Válido Válido Válido DC

En el caso en que se solicite rehacer la Recomendación Curricular, el sistema advierte que se perderá la recomendación que se muestra. De confirmar la solicitud el sistema borra la recomendación y se vuelve a pedir el Periodo de Inicio.

14 DC DC DC DC DC DC DC Cuando el Coordinador solicita comenzar la

28



consulta de otro estudiante, el sistema advierte que borrará todos los datos introducidos por el Coordinador (salvo los cambios de preferencia) o calculados por el sistema. De confirmar el Coordinador la solicitud, el sistema solicita nombre y carnet del estudiante. (Se devuelve al ítem 2 del caso de uso Elaborar Recomendación Curricular).

15 DC Válido DC DC DC DC Válido

Si en el ítem 6 el Coordinador solicita cambiar el Calendario Curricular del pensum el sistema muestra el Calendario Curricular solicitado.

16 DC DC DC DC DC DC Inválido

Se muestra un mensaje de error indicando que el Calendario Curricular Alterno es inválido.

17 Válido DC Válido Válido DC DC Válido

Si en el ítem 11 o 15 el coordinador solicita cambiar el Calendario Curricular Actual. Si el Sistema ha construido previamente la recomendación para el Calendario Curricular actual y el estado del estudiante vigente entonces se muestra la Recomendación, se muestra el Calendario seleccionado y pasa al ítem 5. Si el sistema no ha construido la Recomendación para ese Calendario y estado, cambia el Calendario, se muestra el seleccionado y pasa al ítem 5. En el ítem 5 inicia la determinación del Estado del Estudiante.

18Nulo

Válido Válido Válido DC DC VálidoSi en el ítem 11 o 15 el coordinador solicita cambiar el Calendario Curricular Actual. Si el Sistema ha construido previamente la recomendación para el Calendario Curricular actual y el estado del

29



estudiante vigente entonces se muestra la Recomendación, se muestra el Calendario seleccionado y pasa al ítem 5. Si el sistema no ha construido la Recomendación para ese Calendario y estado, cambia el Calendario, se muestra el seleccionado y pasa al ítem 5. En el ítem 5 inicia la determinación del Estado del Estudiante.

19 Nulo Válido Válido Válido DC DC Válido

Si en el momento en que ocurre un empate, se despide o salva el Documento el Coordinador solicita rehacer la Recomendación el Sistema advierte que la Recomendación que se muestra se perderá. De confirmar la solicitud el sistema borrará la Recomendación.

20 Válido Nulo Válido Válido DC DC Válido

Si en el momento en que ocurre un empate, se despide o salva el Documento el Coordinador solicita rehacer la Recomendación el Sistema advierte que la Recomendación que se muestra se perderá. De confirmar la solicitud el sistema borrará la Recomendación.

30




Items:11, 12, 13, 14, 15, 16. Alternativas:3, 4, 6.


Variante

Recomendación Curricular

Nombre de documento

Localidad del documento

Nombre de documento de preferencia

Localidad de documento de preferencia

RAM

1 Válido Válido Válido DC DC Válido Se salva el documento con el nombre y la localidad indicadas.

2 Inválido DC DC DC DC DCSe muestra un mensaje de error indicando que la Recomendación Curricular es inválida.

3 Válido Inválido DC DC DC DCSe muestra un mensaje de error indicando que el Nombre del Documento es inválido. Se permite al usuario introducir un nuevo valor.

4 Válido Válido Inválido DC DC DCSe muestra un mensaje de error indicando que el Localidad del Documento es inválida. Se permite al usuario introducir un nuevo valor.

31



5 Válido Válido Válido DC DC Inválido Se muestra un mensaje de error indicando que el Rastro Auditable Mínimo es inválido.

6 Válido Nulo nulo Inválido DC DCSe muestra un mensaje de error indicando que el Nombre de Documento de preferencia es inválida. Se permite al usuario introducir un nuevo valor.

7 Válido Nulo nulo Válido Inválido DCSe muestra un mensaje de error indicando que el Localidad de Documento de preferencia es inválida. Se permite al usuario introducir un nuevo valor.

8 Válido Nulo nulo Válido Válido Inválido Se muestra un mensaje de error indicando que el Rastro Auditable Mínimo es inválido.

9 Válido Nulo nulo Válido Válido Válido Se salva el documento con el nombre y la localidad indicadas.

10 DC DC DC DC DC DC


32



Caso de Uso Determinar el Estado del Estudiante

Variable Clasificación Dominio TipoCalendario Curricular Actual Ambiente Corresponde al pensum nuevo o al pensum

viejo.Distinto de nulo.

CalendarioCurricular

Calendario Curricular Alterno Ambiente Distinto de nulo y vacío. CalendarioCurricularCalendario Curricular de Preferencia Ambiente Distinto de nulo y vacío. CalendarioCurricularCódigo de Encajable Aprobado Entrada Formato: xx-yyyy

/ x: a-z ; y: 0-9String

Código de Encajable Entrada Formato: xx-yyyy / x: a-z ; y: 0-9

String

Código de Periodo Aprobado Entrada 1..15 EnteroCódigo de Periodo Entrada 1..15 EnteroCódigo de Año Aprobado Entrada 1..5 EnteroCódigo de Año Entrada 1..5 EnteroCréditos Aprobados en Bloques Heterogéneos.

Entrada Enteros mayores o iguales que cero. Entero

Elementos Extra-Pensum Entrada/Salida Cada elemento consta de:- Código del encajable.- Nombre del encajable- Abreviación del encajable.- Número de créditos (opcional)

Elementos Extra-Pensum

Observaciones Entrada/Salida Cualquier cadena de caracteres es válida. StringElementos Extra-Curriculares Entrada/Salida Cada elemento consta de:

- Código del encajable.- Nombre del encajable- Abreviación del encajable.- Número de créditos (opcional)

Elementos Extra-Curriculares

Pensum de Preferencia Ambiente Pensum Viejo, Pensum Nuevo PensumPesum Actual Ambiente PensumViejo, PensumNuevo PensumPesum Alterno AmbientePeriodo de Inicio de Preferencia Ambiente 1..15 EnteroDocumento Salida

33



Nombre del Documento Entrada/Salida String El nombre del documento no debe excederse de 7 caracteres y solo puede constar de números y/o letras. Puede ser nulo

Localidad del Documento Entrada/Salida String Debe ser un camino de archivo valido para DOS. Cada uno de los directorios dentro del camino debe existir y respetar la jerarquía expuesta en el camino.Puede ser nulo.

Nombre del Documento de Preferencia Entrada/Salida String El nombre del documento no debe excederse de 7 caracteres y solo puede constar de números y/o letras.

Localidad del Documento de Preferencia Entrada/Salida String Debe ser un camino de archivo valido para DOS. Cada uno de los directorios dentro del camino debe existir y respetar la jerarquía expuesta en el camino.

RAM Salida RAM Debe contener: - Versión del programa.- Fecha de los archivos

sobre los cuales se apoya un documento.


Items:2,3 Alternativas:1, 4, 6, 9, 10

Variables Operacionales Respuesta del SistemaVariante Códigos de

Encajables Aprobados

Créditos Aprobados en Bloques Heterogéneos

Código de Periodo Aprobado

Código de Año Aprobado

Calendario Curricular

Calendario Curricular

34



Alterno Actual

1 Válido Válido Válido Válido Válido VálidoSe muestran las asignaturas, periodos y créditos aprobados en bloques heterogéneos del Calendario Curricular.

2 Inválido DC DC DC DC DCSe muestra un mensaje de error indicando que el Código del Encajable es inválido.

3 DC Inválido DC DC DC DCSe muestra un mensaje de error indicando que el Código del Encajable es inválido.

4 DC DC Inválido DC DC DCSe muestra un mensaje de error indicando que el Código del Periodo Aprobado es inválido.

5 DC DC DC Inválido DC DCSe muestra un mensaje de error indicando que el Código del Año Aprobado es inválido.

6 DC DC DC DC DC DC


7 DC DC DC DC DC DC Cuando el coordinador solicite rehacer el estado el Sistema Advierte que se

35



perderán las aprobaciones realizadas.

8 DC DC DC DC Válido Válido

El coordinador solicita un cambio de Calendario Curricular dentro de un mismo Pensum. El Sistema mantiene el mismo Pensum y muestra los Calendarios Curriculares que pertenecen a ese Pensum. El Coordinador selecciona el Calendario Curricular y el Sistema determina el estado del estudiante basándose en el Calendario Curricular anterior.

9 DC DC DC DC Inválido DCSe muestra un mensaje de error indicando que el Calendario Curricular Alterno es inválido.

10 DC DC DC DC Inválido DCSe muestra un mensaje de error indicando que el Calendario Curricular Actual es inválido.


Items:4, 5. Alternativas:2, 4, 6, 9, 10

Variables Operacionales Respuesta del SistemaVariante Pensum Actual Código del

EncajableCódigo de Periodo Código del Año

1 Válido: “Pensum Viejo” Válido Válido Válido

Se muestran los elementos aprobados en el Calendario Curricular correspondiente del Nuevo Pensum según las reglas de equivalencia aplicadas, si existen, los Elementos Extra-Pensum y las Observaciones en formato libre.

2 Válido:“Pensum Nuevo”

Válido Válido Válido El sistema advierte que todos los cambios hechos por la aplicación de equivalencias se perderán de proseguir con la acción, se le

36



permite al coordinador indicar si desea proseguir con el cambio de pensum o si prefiere cancelar la acción. De proseguir, ejecuta las acciones advertidas y permite realizar modificaciones sobre el Calendario Curricular del Pensum Viejo.

3 Inválido DC DC DCSe muestra un mensaje de error indicando que el Pensum Actual es inválido.

4 Válido Inválido DC DC Se muestra un mensaje de error indicando que el Código del Encajable es inválido.

5 Válido DC Inválido DC Se muestra un mensaje de error indicando que el Código del Periodo es inválido.

6 Válido DC DC Inválido Se muestra un mensaje de error indicando que el Código del Año es inválido.

7 DC DC DC DC

Cuando el Coordinador solicita comenzar la consulta de otro estudiante, el sistema advierte que borrará todos los datos introducidos por el Coordinador (salvo los cambios de preferencia) o calculados por el sistema. De confirmar el Coordinador la solicitud, el sistema solicita nombre y carnet del estudiante. (Se devuelve al ítem 2 del caso de uso Elaborar Recomendación Curricular).

8 DC DC DC DCCuando el coordinador solicite rehacer el estado el Sistema Advierte que se perderán las aprobaciones realizadas.

9 Valido DC DC DC


37




Items:6,7 Alternativas:3, 4, 6, 9, 10


VarianteCalendario Curricular Actual

Nombre de documento

Localidad del documento

Nombre de documento de preferencia

Localidad de documento de preferencia

RAM

1 Válido Válido Válido DC DC VálidoSe salva el documento con el nombre y la localidad indicadas.

38



2 Inválido DC DC DC DC DCSe muestra un mensaje de error indicando que el Calendario Curricular Actual es inválido.

3 Válido Inválido DC DC DC DC

Se muestra un mensaje de error indicando que el Nombre del Documento es inválido. Se permite al usuario introducir un nuevo valor.

4 Válido Válido Inválido DC DC DC

Se muestra un mensaje de error indicando que el Localidad del Documento es inválida. Se permite al usuario introducir un nuevo valor.

5 Válido Válido Válido DC DC InválidoSe muestra un mensaje de error indicando que el Rastro Auditable Mínimo es inválido.

6 Válido nulo nulo Inválido DC DC

Se muestra un mensaje de error indicando que el Nombre de Documento de preferencia es inválida. Se permite al usuario introducir un nuevo valor.

7 Válido nulo nulo Válido Inválido DC

Se muestra un mensaje de error indicando que el Localidad de Documento de preferencia es inválida. Se permite al usuario introducir un nuevo valor.

8 Válido nulo nulo Válido Válido InválidoSe muestra un mensaje de error indicando que el Rastro Auditable Mínimo es inválido.

9 Válido nulo nulo Válido Válido VálidoSe salva el documento con el nombre y la localidad indicadas.

10 DC DC DC DC DC DC Cuando el Coordinador solicita comenzar la consulta de otro estudiante, el sistema advierte que borrará todos los datos

39



introducidos por el Coordinador (salvo los cambios de preferencia) o calculados por el sistema. De confirmar el Coordinador la solicitud, el sistema solicita nombre y carnet del estudiante. (Se devuelve al item 2 del caso de uso Elaborar Recomendación Curricular).

11 DC DC DC DC DC DCCuando el coordinador solicite rehacer el estado el Sistema Advierte que se perderán las aprobaciones realizadas.

12 Válido DC DC DC DC DC


40




Items:8,9 Alternativas:4, 6, 10

Variables Operacionales Respuesta del SistemaVariante Pensum Actual1 Válido:

“Pensum Viejo” No se permite elaborar la Recomendación Curricular.

2 Válido:“Pensum Nuevo” Se procede a elaborar la Recomendación Curricular.

3 Inválido Se muestra un mensaje de error indicando que el Pensum Actual es inválido.

4 DC


5 Válido


41



Relaciones operacionales para el componente 5:Este componente es común para ambos casos de uso.Componente 5:

Alternativas:5.

Variables Operacionales Respuesta del SistemaVariante Calendario

Curricular de Preferencia

Pensum de Preferencia

Periodo de Inicio de Preferencia

Nombre de Documento de Preferencia

Localidad del Documento de Preferencia

1 Válido Válido Válido Válido Válido El sistema registra los cambios realizados a las preferencias.

2 Inválido DC DC DC DC Se muestra un mensaje de error indicando que el Calendario Curricular de Preferencia es inválido y se solicita un valor nuevo.

3 DC Inválido DC DC DC Se muestra un mensaje de error indicando que el Pensum de Preferencia es inválido y se solicita un valor nuevo.

4 DC DC Inválido DC DC Se muestra un mensaje de error indicando que el Periodo de Inicio de Preferencia es inválido y se solicita un valor nuevo.

5 DC DC DC Inválido DC Se muestra un mensaje de error indicando que el Nombre del Documento de Preferencia es inválido y se solicita un valor nuevo.

6 DC DC DC DC Inválido Se muestra un mensaje de error indicando

42



que la Localidad del Documento de Preferencia es inválido y se solicita un valor nuevo.

Relaciones operacionales para el componente 6:Este componente es común para ambos casos de uso.Componente 6:

Alternativas: 7 y 8 (Caso de Uso Determinar Estado del Estudiante). Alternativa: 7 (Caso de Uso Elaborar Recomendación Curricular).

Variables Operacionales Respuesta del SistemaVariante Observaciones Elementos

Extra-PensumElementos Extra-Curriculares

1 Válido Válido VálidoEl sistema registra y muestra las observaciones, elementos extra-pensum y elementos extra-curriculares.

2 DC Inválido DCSe muestra un mensaje de error indicando que los Elementos Extra-Pensum son inválidos y se solicitan valores nuevos.

3 DC DC InválidoSe muestra un mensaje de error indicando que los Elementos Extra-Pensum son inválidos y se solicitan valores nuevos.


Alternativas:11, 12, 13

43



Variables Operacionales Respuesta del SistemaVariante Pensum Actual Pensum Alterno

1 Válido: “Pensum Viejo”

Válido:“Pensum Nuevo”

Si el Coordinador solicita cambio al Pensum nuevo el Sistema aplica las equivalencias, muestra el nuevo estado y continua con la determinación del Estado de Estudiante.


Válido:“Pensum Viejo”

Si el Coordinador solicita cambio al Pensum nuevo el Sistema advierte que las aprobaciones realizadas por equivalencias se pierden. De confirmar el coordinador su solicitud el sistema ejecuta las acciones advertidas y presenta el estado previo al pase al nuevo Pensum y continua con la determinación del Estado del Estudiante.


Válido:“Pensum Nuevo”

Se muestra un mensaje de error indicando que el estado del Sistema es inválido.

4 Válido:“Pensum Viejo”

Válido:“Pensum Viejo”

Se muestra un mensaje de error indicando que el estado del Sistema es inválido.

5 Inválido DC Se muestra un mensaje de error indicando que Pensum Actual es inválido.

6 DC Inválido Se muestra un mensaje de error indicando que Pensum Alterno es inválido.

44

plan de pruebas de delta pensum 1

Documents