MXPA00000613A - Sistema y metodo para generar casos de prueba del año 2000 - Google Patents

Abstract

Se describe un método y sistema basado en una regla innovadora para crear casos de pruebas para la prueba de acuerdo al año 2000, de sistemas de programas. El usuario primero introduce información como reglas relacionadas al lógico de negocios del sistema. Después de obtener el lógico de negocios, el sistema transformará(220, 230, 240), los casos de prueba de entrada en casos de prueba de salida, para la prueba de acuerdo con el año 2000. El sistema compara (220), los casos de prueba de entrada, y en base al lógico de negocios, identifica las variables o constantes que dependen de la fecha, hora o duración ("campos dependientes de la fecha"), en los casos de prueba. Las fechas con riesgo, horas o duraciones, se sustituyen por el campo dependiente de la fecha para preserfar el lógico de negocios. El sistema puede adaptarse para manejar cualquier tipo de cambio de hora en el sistema, por ejemplo, cuando los números telefónicos de siete tipos de cambio se reemplazan por un solo tipo de cambio.

Description

SISTEMA Y MÉTODO PARA GENERAR CASOS DE PRUEBA DEL AÑO 2000 Campo Técnico La presente invención se relaciona en general, con sistemas y métodos para probar aplicaciones para el cur lirniento con condiciones predeterminadas, y de manera más particular, con sistemas y métodos para determinar si las aplicaciones están "de acuerdo con el año 2000", y pueden procesar correctamente datos tanto de los siglos 20 como 21.

Técnica Antecedente Durante décadas, ha sido una práctica común el representar el año en sistemas de procesamiento de datos utilizando dos dígitos en . lugar de cuatro. Así, el año "1995" se representa (y con frecuencia se almacena) utilizando los dos últimos dígitos "95". Esta práctica minimiza el espacio en la memoria caro y el tiempo de introducción de los datos. En el Año 2000 ("Y2K) , muchos sistemas interpretarán los dos dígitos del año "00" como que significan el año 1900, un resultado no deseado obvio, de tratar con fechas representadas utilizando sólo dos dígitos. Este problema es agudo, y si una organización no toma los pasos necesarios para hacer sus sistemas "de acuerdo con el Año 2000", entonces puede enfrentar severas consecuencias de negocios. Por ejemplo, los registros de los pagos de las tarjetas de crédito, los REF. : 32272 reembolsos de los impuestos IRS y aún los sistemas de control de tráfico que mantienen a los aviones separados de manera segura, pueden alterarse. Un sistema "de acuerdo con el Año 2000", es uno el cual puede operar correctamente con fechas que pertenecen tanto a los siglos 20 como 21. Debido a su alcance y a la restricción del tiempo, el arreglo del "fallo" del Y2K, impone desafíos formidables. El costo para arreglar el problema del Y2K en todo el mundo, se estima que será de cientos de billones de dólares. Considerando el tiempo y los recursos requeridos, las herramientas automatizadas tendrán un papel significativo en los esfuerzos para hacer las aplicaciones, de acuerdo con el Y2K. De manera general, los esfuerzos de conversión del Y2K, involucran un proceso de dos pasos: primero, el sistema debe ser convertido para hacerlo de acuerdo al Y2K, y segundo, el ' sistema debe ser probado totalmente para asegurar que se ha convertido correctamente. El segundo paso de "depuración", con frecuencia resulta que consume más tiempo y costos que el paso de conversión real, en sí mismo. Mientras que numerosas herramientas de conversión del código/sistema automáticas, están ahora disponibles para el primer paso de los esfuerzos de conversión al Y2K, parece que faltan, universalmente, una disciplina de prueba y herramientas de prueba automatizadas, para el segundo paso.

DsGripción de la Invención Para lograr los objetos y de acuerdo con el propósito de la invención, como se incorpora y describe ampliamente en la presente, el método de la presente invención que genera casos de prueba para utilizarse en la prueba de acuerdo al Año 2000, de un sistema a prueba, realizado por un procesador de datos, comprende: proporcionar al procesador de datos uno o más casos de prueba de entrada, que correspondan al sistema a prueba; identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha en cada uno del uno o más casos de prueba de entrada; y generar de manera selectiva, de acuerdo a un segundo conjunto de criterios predeterminados, uno o más casos de prueba de salida, donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de salida, incluye una fecha arriesgada de un conjunto de fechas con riesgo utilizadas para la prueba de acuerdo al Año 2000. En otro aspecto, la invención comprende: una interfaz para recibir uno o más casos de prueba de entrada que corresponden al sistema a prueba; un dispositivo de comparción para identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha en uno o más casos de prueba de entrada; y un componente de generación configurado para generar selectivamente, de acuerdo con un segundo conjunto de criterios predeterminados, uno o más casos de prueba de salida, donde al menos uno de los campos dependientes de la la fecha en cada caso de prueba de salida, incluye una fecha con riesgo de un conjunto de fechas con riesgo, utilizadas para la prueba de acuerdo con el Año 2000. En un aspecto adicional, el medio legible por computadora de la presente invención, es capaz de configurar un procesador de datos para generar casos de prueba para utilizarse en una prueba de acuerdo al Año 2000 de un sistema a prueba, el medio comprende un código de programa para hacer que el procesador de datos realice los pasos de: identificar de acuerdo a un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno del uno o más casos de prueba de entrada, que corresponden al sistema a prueba, y generar selectivamente, de acuerdo a un segundo conjunto de criterios predeterminados, uno o más casos de prueba de salida, donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de salida, incluye una fecha arriesgada de un conjunto de fechas con riesgo utilizadas para la prueba de acuerdo al Año 2000. Se entenderá que tanto la descripción general, anterior, como la siguiente descripción detallada, son sólo ejemplares y explicativas, y no restringen la invención, como se reivindica.

Breve Descripción de los Dibujos Los dibujos acompañantes, los cuales se incorporan en, y constituyen una parte de esta especificación, ilustran las implementaciones de la invención, y junto con la descripción, sirven para explicar los principios de la invención. En las Figuras: La Figura 1 es un diagrama de flujo, que ilustra los pasos realizados por un sistema consistente con la presente invención. La Figura 2 es un diagrama de bloques que muestra una arquitectura para un sistema de computadora, con la cual, los sistemas consistentes con la presente invención, pueden implementarse; La Figura 3 es un diagrama de bloques de cinco módulos principales, consistentes con la presente invención; La Figura 4 es un diagrama de bloques, que ilustra cómo el Dispositivo de Reconocimiento, el Dispositivo de Generación y el Dispositivo de Sustitución, generan casos de prueba de salida de los casos de prueba de entrada, de una manera consistente con la presente invención; y La Figura 5 es un diagrama de bloques que ilustra cómo los casos de prueba de salida son generados de los casos de prueba de entrada.

Mejor Modo Para Llevar a Cabo la Invención Se hace ahora referencia en detalle a las implementaciones de la presente invención, un ejemplo de la cual, se ilustra en los dibujos acompañantes. Donde sea apropiado, los mismos números de referencia, se refieren a los mismos o similares elementos. Las reivindicaciones anexas definen el alcance de la invención, y la siguiente descripción no limita ese alcance. Los sistemas y métodos consistentes con la presente invención, proporcionan un método basado en una regla innovador, automatizado, dirigido a los aspectos de prueba de los esfuerzos de conversión para el Y2K. Los sistemas y métodos inicialmente reciben un conjunto de los llamados "casos de prueba de entrada", que incluyen varios campos que involucran fechas, horas, y duraciones, y a continuación, enumera sistemáticamente varios "casos de prueba de salida", que corresponden a escenarios que involucran fechas, horas y duraciones, los cuales probablemente revelen si un sistema a prueba ("SUT") está de acuerdo con el Y2K. Un caso de prueba contiene varias fechas, horas y duraciones, y es generalmente del formato que puede ser introducido de manera conveniente al SUT para la ejecución. Un caso de prueba de entrada, tiene varios campos dependientes de la fecha, pero no necesariamente tiene fechas, horas y duraciones que sean particularmente relevantes para la prueba de conversión para el Y2K. Por ejemplo, un caso de prueba de entrada puede derivarse de instantáneas de datos de transacciones ordinarias, capturados utilizando una herramienta de registro. En base a los casos de prueba de entrada, los sistemas y métodos consistentes con la presente invención, generan casos de prueba de salida. Los casos de prueba de salida serán del mismo formato que los casos de prueba de entrada, pero contendrán las llamadas "fechas con riesgo del Año 2000" — fechas, horas y duraciones que probablemente revelen cualesquier defectos en el SUT, con respecto a la conversión del Y2K. Aquellas fechas con riesgo del Y2K, incluyen, por ejemplo: Diciembre 31, 1999; Enero 1, 2000; y Febrero 29, 2000. Los casos de prueba de salida que contienen estas fechas con riesgo del Y2K, pueden ser ejecutados posteriormente por el SUT, para determinar si el SUT se ha convertido exitosamente. Los sistemas y métodos consistentes con la presente invención, tienen aplicaciones más allá de la prueba de acuerdo al Y2K. Pueden retroajustarse para tratar con la generación de los casos de prueba para cualquier cambio de hora en un sistema de programas. Por ejemplo, aquellas aplicaciones pueden incluir situaciones donde los números telefónicos de siete dígitos son reemplazados por diez dígitos, cambios en el código de área, o varias tipos de cambios son reemplazados por una sola unidad de tipo de cambio, y así sucesivamente. La Figura 1 es un diagrama de flujo que ilustra los pasos ejecutados por un sistema consistente con la presente invención. El sistema recibe los casos de entrada de prueba (paso 310) . El tiempo y esfuerzo que para generar los datos de prueba de entrada para el sistema son minimizados debido a que el sistema utiliza ya sea los casos de prueba existentes o los casos de prueba que son generados fácilmente por el registro de transacciones ordinarias del SUT. Una de tales herramientas disponible comercialmente (también referida como un equipo de prueba), es el MYNAH 4.3. Este paso para recibir los casos de prueba de entrada (paso 310), se lleva a cabo a través de una Interfaz de Usuario ("UI") y se discute con mayor detalle en la sección en el UI posterior. A continuación, el sistema consistente con la presente invención explora los casos de prueba de entrada e identifica los campos dependientes de la fecha, así como los campos sin fecha relevantes (referidos de aquí en adelante como campos "de prueba"), en los casos de prueba de entrada y las localizaciones de los mismos (paso 320) . Este paso de exploración e identificación se refiere como el paso de "reconocimiento". El paso de reconocimiento se lleva a cabo por el sistema basado en las reglas de reconocimiento provistas por el usuario y por el sistema con respecto al formato de los casos de prueba de entrada, en cuanto a donde y en que formato los campos dependientes de la fecha y los campos de prueba están dentro del caso de prueba de entrada (ver el paso 322) . En este paso de reconocimiento, el sistema puede también generar reportes de resumen para el usuario, indicando si cualesquiera de las reglas de reconocimiento provistas por el usuario, son potencialmente incorrectas o incompletas (ver paso 324). Un conjunto de reglas de reconocimiento provistas por el usuario es potencialmente incorrecto si, por ejemplo, un valor de los datos no se encuentra en el campo que el usuario indicó que es un campo dependiente de la fecha. Las reglas de reconocimiento provistas por el -• usuario pueden ser potencialmente incompletas si durante el paso de reconocimiento, el sistema encuentra campos dependientes de la fecha que no se tomaron en cuenta por cualesquiera de las reglas de reconocimiento provistas por el usuario. El usuario puede revisar los reportes de resumen y modificar las reglas de reconocimiento conforme se necesite. Este paso de reconocimiento se lleva a cabo por un Dispositivo de Reconocimiento ("PE"), y se discute con mayor detalle en la sección del PE, posteriormente.

Una vez que el sistema ha identificado y localizado los campos dependientes de la fecha y los campos no relevantes sin fecha en los casos de prueba de entrada, el sistema genera selectivamente casos de prueba de salida (paso 330) . Los casos de prueba de salida son esencialmente copias de los casos de prueba de entrada y son del mismo formato que los casos de prueba de entrada. Sin embargo, los campos dependientes de la fecha de los casos de prueba de salida contienen fechas con riesgo del Y2K, tales como Diciembre 31, 1999 y Enero 1, 2000. Nótese que los casos de prueba de salida se generan selectivamente. Para ilustración, considerar una situación relativamente simple, donde hay diez campos dependientes de la fecha en un caso de prueba y tres fechas con riesgo a probarse. Sin la generación selectiva, el total de posibles casos de prueba sería de 310, o casi 60,000. Este paso de generación selectiva de los casos de prueba de salida se lleva a cabo en dos pasos, por el Dispositivo de Generación ("GE"), y un Dispositivo de Sustitución ("SE"), y se discute con mayor detalle en las secciones del GE y SE posterior. Los casos de prueba de salida que contienen estas fechas con riesgo del Y2K, pueden ejecutarse posteriormente por la SUT para determinar si los defectos que existen hacen que la SUT falle en la prueba de acuerdo con el Y2K (paso 340) . En una implementación, esto se hace primero ejecutando los casos de prueba de salida en la SUT y comparando las salidas de la SUT de la misma, con las salidas de la SUT que ya se sabe que son correctas. Una manera para generar las salidas de la SUT que ya se sabe que son correctas, es utilizar una regla conocida como la regla de repetición de 28 años. Este paso de determinar si la SUT está de acuerdo con el Y2K, utilizando los casos de prueba de salida se lleva a cabo por el Simulador de Salida ("OS"') y se describe con mayor detalle en la sección del OS posterior. La Figura 2 ilustra la arquitectura del sistema para un sistema de computadora con el cual los sistemas consistentes con la presente invención pueden implementarse. El sistema de computadora 100 incluye un cable de interconexión 102 o algún otro mecanismo para comunicar información, y un procesador 104 ' acoplado con el cable de interconexión 102 para procesar información. El sistema de computadora 100 también incluye una memoria principal, tal como una memoria de acceso aleatorio (RAM) 106 u otro dispositivo de alitiacenamiento dinámico, acoplado al cable de interconexión 102 para almacenar información e instrucciones a ser ejecutadas por el procesador 104. La RAM 106 también puede utilizarse para almacenar variables tempoerales u otra información intermedia, durante la ejecución de las instrucciones a ser ejecutadas por el procesador 104. El sistema de computadora 100 incluye, además, una memoria de sólo lectura (ROM) 108, u otro dispositivo de almacenamiento estático, acoplado al cable de interconexión 102, para almacenar información estática e instrucciones del procesador 104. Un dispositivo de almacenamiento 110, tal como un disco magnético o un disco óptico, se proporciona y se acopla al cable de interconexión 102, para almacenar la información y las instrucciones. El sistema de computadora 100 puede estar acoplado vía el cable de interconexión 102 a una pantalla 112, tal como un tubo de rayos catódicos (CRT) , para representar la información a un usuario de la computadora. Un dispositivo de entrada 114, que incluye teclas alfanu éricas y otras, se acopla al cable de interconexión 102 para comunicar la información y selecciones de órdenes al procesador 104. Otro tipo de dispositivo de entrada del usuario es el control del indicador (cursor) 116, tal como un ratón, una esfera de trazado o teclas de dirección del indicador, para comunicar información y selecciones de órdenes al procesador 104, y para controlar el movimiento del indicador en la pantalla 112. El término "medio legible por computadora", como se utiliza en la presente, se refiere a cualquier medio que participa en la proporción de instrucciones al procesador 104 para la ejecución. Tal medio puede tomar muchas formas, incluyendo, por ejemplo, un disco flexible, un disco duro, una cinta magnética, o cualquier otro medio magnético, un CD- ROM, o cualquier otro medio desde el cual una computadora pueda leer. El sistema de computadora 100 también incluye una interfaz de comunicación 118 acoplada al cable de interconexión 102. La interfaz de comunicación 118 proporciona un acoplamiento de comunicación de datos de dos vías, a un enlace 120 que está conectado a una red 122. Por ejemplo, la interfaz de comunicación 118 puede ser una tarjeta de red de área local (LAN) o una tarjeta de red digital de servicios integrados (ISDN) o un módem, para proporcionar una conexión de comunicación de datos a una LAN o a la Internet y a la Red Mundial ("WWW"). Un medio de generación de prueba para el Y2K, consistente con la presente invención, puede ser implementado utilizando la computadora 100. El medio de generación de prueba para el Y2K, también puede ser accesible vía la Internet o la Red Mundial ("WWW"). El procesador 104 ejecuta una o más secuencias de una o más instrucciones del medio de generación de prueba para el Y2K, el cual puede ser almacenado en la memoria principal 106. Tales instrucciones pueden leerse en la memoria principal 106 desde otro medio legible por computadora, tal como un dispositivo de almacenamiento 110. La ejecución de las secuencias de instrucciones contenidas en la memoria principal 106, hace que el procesador 104 realice los pasos del proceso descritos en la presente. En una implementación alternativa, puede utilizarse un circuito cableado permanentemente en lugar de, o en combinación con las instrucciones de los programas para implementar la invención. Así, las implementaciones de la invención no se limitan a alguna combinación específica de circuitos cableados permanentemente y de programas. La Figura 3 muestra cinco módulos de un sistema consistente con la presente invención: (1) Interfaz del Usuario ("UI") (210); (2) Dispositivo de Comparación ("PE") (también referido como un Dispositivo de Identificación o de Exploración) (220) ; (3) Dispositivo Generador de Prueba ("GE") (230); (4) Dispositivo de Sustitución ("SE") (240); y (5) Simulador de Salida ("OS") (250). • • Cada uno de los cinco módulos se explica en detalle como sigue.

A. INTERFAZ DEL USUARIO ("UI") La interacción entre el sistema de la presente invención y el usuario, ocurre a través de la UI. Las entradas del usuario incluyen: (1) casos de prueba de entrada reales, junto con un archivo del catálogo que lista los nombres del archivo de los casos de prueba de entrada; (2) reglas de reconocimiento para identificar los campos dependientes de la fecha dentro de los casos de prueba de entrada; (3) reglas de reconocimiento para identificar los campos sin fecha (referidos de aquí en adelante como "campos de prueba"), que pueden ser .necesarios para generar casos de prueba de salida; (4) información acerca de la herramienta de registro (también referida como el equipo de prueba) , utilizada para capturar los casos de prueba de entrada; (5) una lista de fechas con riesgo, tales como Diciembre 31, 1999, Enero 1, 2000, e información de festividades; (6) reglas que expresan las restricciones entre las fechas, y (7) otra información varia, tal como el nombre de los directorios, donde los casos de prueba de salida deben almacenarse . En una implementación, la interfaz del usuario del sistema de generación de prueba para el Y2K proporciona una interfaz basada en la Red Mundial ("WWW"), para que los usuarios interactúen con el sistema. Esto permite que aún los usuarios localizados de manera distante (y sistemas a prueba) , proporcionen casos de prueba de entrada sobre la WWW al sistema de generación de prueba para el Y2K de la presente invención, y que reciban los casos de prueba de salida sobre la WWW, de modo que la prueba de acuerdo con el Y2K pueda hacerse localmente, donde los usuarios están localizados. 1. Acceso Asegurado (UI) En una implementación, la interfaz del usuario se desarrolla en la WWW, y cualquiera puede tener acceso al sistema si saben el localizador de recurso uniforme ("URL"), y tienen un Navegador de la Red generalmente disponible comercialmente. Para evitar el acceso no autorizado al sistema de generación de prueba para el Y2K, consistente con la presente invención, puede proporcionarse una característica de seguridad basada en una contraseña. Así, sólo los usuarios con nombres de registro y contraseñas correctos, serán capaces de tener acceso a utilizar el sistema de generación de prueba. El sistema también puede proporcionar diferentes niveles de seguridad, y permiso de acceso para los usuarios. Por ejemplo, el administrador del sistema de generación de prueba del Y2K, será capaz de registrarse con todos los permisos de acceso posibles, mientras que otros pueden no ser capaces de obtener el permiso para ver la información acerca de otros usuarios del sistema o datos. Una vez que el usuario se registra, la sesión actual permanece activa hasta que el usuario finaliza la sesión o no está utilizando activamente el sistema durante un periodo predeterminado. Así, el mecanismo de tiempo fuera se mantiene para cada usuario, para asegurar que el dejar el navegador encendido, no comprometerá los datos sensibles.

Esta característica de seguridad facilita no sólo a los usuarios, sino también para correr el servicio tanto dentro de intrarredes corporativas como Internets, grandes, dentro de la corporación. 2. Entradas a Través de la Páginas de Preparación o Inicio (UI) Dependiendo del privilegio del usuario, se representan diferentes páginas iniciales para diferentes usuarios. Así, la UI (210) permite el ajuste de la apariencia y configuración del sistema de generación de prueba para el Y2K de la presente invención para usuarios individuales. Los usuarios normales pueden empezar por tener acceso al sistema del Y2K con una página de preparación o inicio de nivel superior, que represente un conjunto de herramientas de registro soportadas por el sistema Y2K. Como se explicó anteriormente, una herramienta de registro se refiere a un programa de registro particular, utilizado para registrar las transacciones del sistema para generar los casos de prueba de entrada. Después de la selección de la herramienta de registro, el usuario puede introducir información adicional, tal como la localización de los casos de prueba de entrada, el directorio objetivo para los casos de prueba de salida y así sucesivamente. Está página de preparación o inicio es configurable, y proporciona suficiente flexibilidad para agregar nuevas herramientas de registro. Aparte de la página de preparación o inicio de alto nivel, principal, pueden proporcionarse dos páginas adicionales de preparación o inicio, para introducir la información requerida por el Dispositivo de Comparación 220, y el Dispositivo de Generación 230, respectivamente. La segunda página de preparación o inicio permite que el usuario especifique, examine y edite las reglas de comparación para identificar los campos dependientes de la fecha y el archivo del catálogo. La tercer página de preparación o inicio se utiliza para proporcionar entradas para el Dispositivo de Generación 230, que incluye los formatos de fecha a ser utilizados, el nombre del archivo con información de restricciones, el nombre del archivo con fechas con riesgo, opciones de selección para las fechas con riesgo suministradas por el sistema versus la fechas con riesgo suministradas por el usuario, y el grado especificado de optimización a ser utilizado para generar los casos de prueba de salida (modo comprimido o modo exhaustivo y así sucesivamente) . Estas páginas de preparación o inicio aparecen al inicio de cada fase de la operación del sistema. La información recolectada del usuario es validada de manera adecuada, se le da formato y se pasa como una entrada a los dispositivos respectivos. Así, las entradas del usuario de la segunda página de preparación o inicio, se pasan al Dispositivo de Comparación 220 y las entradas de la tercer página de preparación o inicio, se pasan al Dispositivo de Generación 230. 3. Examen y Edición de la Información de Entrada (UI) La UI 210 del sistema de generación de prueba del Y2K, permite que el usuario examine todos los archivos de entrada (por ejemplo, archivo del catálogo, reglas de reconocimiento, y reglas que expresan las restricciones entre las fechas). Además, la UI 210 proporciona la facilidad de edición, para modificar la información contenida en estos archivos de entrada. Así, en cada página de preparación o inicio, el usuario puede examinar, así como editar, la información de entrada. Por ejemplo, si el sistema sospecha que una regla de reconocimiento es incorrecta (por ejemplo, si un campo de fecha no se encuentra donde la regla de comparación de entrada indica que debería estar) , la UI 210 permite que el usuario edite las reglas de reconocimiento y vuelva a presentar las reglas de reconocimiento revisadas inmediatamente. La UI 210 agrega dinámicamente las marcas del Lenguaje de Marcado de Hipertexto ("HTML") adecuadas, para estos archivos, y proporcionan una navegación fácil y los enlaces para editar la información relevante. Las versiones editadas de los archivos son almacenadas de nuevo en el formato original. 4. Examen de las Salidas del Dispositivo de Comparación y Depuración (UI) La UI 210 presenta al usuario un reporte del Análisis de Impacto y Resumen Técnico, de las salidas del Dispositivo de Comparación 220, y permite que los usuarios examinen los mensajes de advertencias y error generados por el Dispositivo de Comparación 220, a varios niveles de detalle. Por ejemplo, la información del Análisis de Impacto de alto nivel es generada dinámicamente por la UI 210 de los archivos de salida del Dispositivo de Comparación 220, y se representa como métricos fáciles de entender en formas tabulares. El Resumen Técnico más detallado es generado dinámicamente por la UI 210, de las salidas del Dispositivo de Comparación, para proporcionar una información técnica detallada, tal como la frecuencia de los campos con fecha dentro de cada caso de prueba de entrada, los nombres de los archivos y así sucesivamente. El Resumen Técnico está dirigido más hacia el Experto de la Materia Objeto ("SME"), mientras que el resumen del Análisis de Impacto se pretende principalmente para proporcionar la complejidad general de los esfuerzos involucrados. La información del Resumen puede representarse en formatos tabulares y de histograma. Además del examen de la información del resumen, el usuario también puede examinar la información de advertencia y error para propósitos de depuración. La información de advertencia y error también se presenta en dos niveles: un resumen y una lista detallada. La información del resumen permite a los usuarios determinar donde ocurren los problemas durante la etapa de comparación. La lista detallada da varias categorías de información de -advertencias y errores, con la ubicación exacta que consiste del nombre del archivo, número de línea, número de columna dentro de una línea y la identificación o el valor en donde el error ocurrió. Esta información es generada dinámicamente con las marcas HTML adecuadas, para proporcionar * varias pistas y enlaces visuales a los documentos de iniciación de prueba reales. Examinando y enfocándose en las ubicaciones de error identificadas por el Dispositivo de Comparación 220, el usuario puede modificar fácilmente las reglas existentes, y volver a ejecutar el Dispositivo de Comparación 220, para obtener una base de reglas completa y correcta. 5. Reportes del Resumen de las Salidas del Dispositivo de Generación (UI) La UI 210 proporciona varios resúmenes de la información con respecto a los casos de prueba de salida generados. Un resumen de información puede ser representado en formatos tabulares y de histograma. Un resumen corto puede proporcionar información tal como el número de casos de prueba de salida generados., varios valores de fechas con riesgo adicionales, generados por el sistema y proporcionados por el usuario, utilizados en los casos de prueba de salida y así sucesivamente. Un resumen detallado proporciona información tal como las restricciones sobresalientes en cada campo con fecha y los valores de los datos utilizados. La UI 210 también permite que el usuario examine los casos de prueba de salida generados recientemente en dos niveles: nivel de directorio y nivel de archivo o caso de prueba individual . 6. Representación del Progreso (UI) La UI 210 proporciona una información de barra de estado para indicar la cantidad de procesamiento hecho. Esta información del estado se proporciona para ambos del Dispositivo de Comparación 220 y el Dispositivo de Generación 230. 7. Páginas de Ayuda (UI) La UI 210 proporciona páginas de ayuda adecuadas y facilidades en todos los niveles. Así, uno puede obtener fácilmente, ayuda en línea instantánea desde la UI 210.

B. DISPOSITIVO DE COMPARACIÓN La Figura 4 es una diagrama de bloques que muestra varias entradas y salidas del Dispositivo de Comparación 220, del Dispositivo de Generación 230 y del Dispositivo de Sustitución 240. Como se muestra en la Figura 4, las entradas al Dispositivo de Comparación 220 incluyen: (1) uno o más casos de prueba de entrada reales; (2) reglas de reconocimiento proporcionadas por el usuario para identificar los campos dependientes de la fecha; (3) reglas de reconocimiento proporcionadas por el usuario para identificar los campos de prueba, que son relevantes para generar casos de prueba de salida; y (4) reglas de reconocimiento proporcionadas por el sistema para identificar automáticamente los campos dependendi'entes de la fecha. En base a estas entradas, el Dispositivo de Comparación identifica y localiza los campos dependientes de la fecha y los campos de prueba relevantes, en los casos de prueba de entrada . Los casos de prueba de entrada pueden proporcionarse directamente al sistema, o de manera alternativa, una lista de los casos de prueba de entrada puede proporcionarse en una forma de un archivo de catálogo. El Dispositivo de Comparación 220 explora los casos de prueba de entrada para buscar secuencias de entrada, las cuales coinciden con las reglas de reconocimiento por defecto proporcionadas por el sistema o proporcionadas por el usuario, para identificar los campos con fecha y de prueba, relevantes. Las reglas de comparación son .especificadas al Dispositivo de Comparación 220 en la forma de tablas de definición de campo. En base a estas reglas de comparación, el Dispositivo de Comparación 220 encuentra y registra todas las coincidencias en las tablas de uso del campo apropiadas: (1) Tabla de Uso del Campo con Fecha ("DFUT") y (2) Tabla de Uso del Campo de Prueba ("TFUT"). Primero, los campos dependientes de la fecha se registran en la DFUT. La tabla de uso del campo de datos, lista la ocurrencia de un campo particular y la ubicación del campo - dentro de un caso de prueba de entrada particular. La tabla de uso del campo de datos es usada posteriormente por el Dispositivo de Generación 230, para generar los valores de los datos a ser utilizados en los casos de prueba de salida. Segundo, los campos que no dependen de la fecha, son registrados en la TFUT. La tabla de uso del campo de prueba lista la ocurrencia de un campo particular y la ubicación del campo dentro de un caso de prueba de entrada particular. La tabla de uso del campo de prueba es usada posteriormente por el Dispositivo de Sustitución 240, para crear los casos de prueba de salida. Además de crear las tablas de uso del campo, el Dispositivo de Comparación 220 registra varias advertencias en un archivo de registro, y la UI 210 utiliza el archivo de registro para proporcionar una retroalimentación al usuario en varios niveles de abstracción. Además, el Dispositivo de Comparación 220 puede ajustarse opcionalmente para buscar relaciones binarias (esto es, menor que, mayor que o igual a) , entre varios campos de datos y registra la información relacionada con estas relaciones en una tabla de frecuencia de restricciones. El Dispositivo de Comparación 220 también tiene una facilidad de autoidentificación integrada, que el usuario puede invocar opcionalmente. Cuando esta opción es invocada, el Dispositivo de Comparación 220 señala todas las fechas que se ven sospechosas, las cuales no son tomadas en cuenta por ninguna de las reglas de comparación proporcionadas por el usuario. El sistema Y2K, a través de la UI 210, puede entonces sugerir al usuario a que modifique y/o agregue reglas de comparación adicionales. El usuario puede aceptar la sugerencia. De manera alternativa, el usuario puede ignorar la sugerencia, si por ejemplo, el usuario no está interesado en el campo de fecha particular señalado por el sistema Y2K. 1. Archivos de Entrada al Dispositivo de Comparación El Dispositivo de Comparación 220 recibe los siguientes archivos de entrada. a. Archivo de Catálogo de Prueba: el Archivo de Catálogo de Prueba contiene un lista jerárquica de los casos de prueba de entrada. El orden de la comparación de los casos de prueba se determina por el listado en el Archivo de Catálogo de Prueba. b. Archivo de Definición de la Regla de Comparación: el Archivo de Definición de la Regla de Comparación consiste de una lista de las reglas que el Dispositivo de Comparación 220 emplea para identificar las secuencias relevantes en los casos de prueba de entrada. Las reglas para identificar las fechas se distinguen de las reglas para identificar pruebas. Puede haber muchas reglas de identificación de fechas. Por ejemplo, las reglas de comparación para identificar fechas pueden incluir: (1) tipo de desplazamiento: Esta regla especifica exactamente donde (por ejemplo, números de página y línea) , en el caso de prueba de entrada particular podría encontrarse un campo de fecha; y (2) tipo de formato de fecha: Esta regla especifica los formatos exactos de las fechas utilizadas en el caso de prueba de entrada, tal como "m /dd/yy", "mm/dd/yyyy" , o "dd/mm/yy" ("mm/dd/aa", "mm/dd/aaaa" , o "dd/mm/aa" ) . c. Tabla de Modelado de la Fecha del Sistema La ejecución de algunos de los casos de prueba puede depender del reloj del sistema (la fecha y hora actuales) . La dependencia en el reloj del sistema puede ser implícita o puede necesitar ser modelada explícitamente. El modelado implícito ocurre cuando en un caso de prueba, el valor asignado a un campo es calculado por un macro/llamada de función, o por una Regla de Fecha Genérica y el valor tiene un SYS en él. Esto pasa sí la expresión en el Macro/Regla de Identificación de Llamada de Función o la Regla de Fecha Genérica se evalúa con la secuencia_SYS en ella. Para modelar explícitamente una dependencia del caso de prueba en el reloj del sistema, uno puede utilizar una Tabla de Modelado de la Fecha del Sistema. d. Tabla de los Patrones de Autoidentificación El Dispositivo de Comparación 220 puede opcionalmente, ajustarse para buscar fechas sospechosas buscando patrones en los casos de prueba de entrada, los cuales no son tomados en cuenta por ninguna de las reglas proporcionadas por el usuario. El usuario puede ajustar el nivel de autoidentificación utilizando la Tabla de los Patrones de Autoidentificación ("AIPT" ) . Lo siguiente es un ejemplo de una AIPT.

# Norteamericano mm-dd-yyyy y na mm-dd-yy y na yyyy-mm-dd y na yy-mm-dd y na mm-dd y na yymmdd y usuario mm/dd/yyyy y na mm/dd/yy y na yyyy/rpm/dd y na yy/mm/dd y na mm/dd y _na # Asiático/Europeo dd-mm-yyyy n asía dd-mm-yy n asía dd-mm n asía dd/mm/yyyy n asía dd/mm/yy n asía dd/mm n asía dd. m . yyyy n _europa dd.m . yy n _europa # Directivos Apagados MSTR apagado La línea o líneas en blanco cuyo primer carácter no en blanco es # son comentarios, y son ignorados por el Dispositivo de Comparación 220. Para las otras líneas, se da una entrada mediante una lista separada por fabulador de los campos. El tipo enumerado (_na, _europa, _asia, o _usuario) , se utiliza para denotar el agrupamiento al cual pertenece la entrada. Los formatos de las fechas anteriores, pueden ser cualquier expresión regular, sin embargo, de, m, yy, yyyy, / y . tienen un significado especial. / no necesita espacio; "dd", "mm", "yy" y "yyyy", no pueden utilizarse sin su significado especial. Los formatos sin separadores (por ejemplo, mmddyy o mmdd) coincidirán con los patrones de entrada con sólo un número específico de bytes. Por ejemplo, mmddyy y mmdd coincidirán con los patrones de 6 y 4 bytes respectivamente; esto es, 0404 pertenece a mmdd, pero 044 no. Un usuario puede afinar la identificación al: (1) modificar los formatos de la fecha en el primer campo; (2) seleccionar/no seleccionar los patrones utilizando "y" o "n"; (3) agregar nuevas entradas; (4) limitar el alcance de una entrada a un tipo de caso de prueba de entrada, indicando tal limitación entre el segundo y el tercer campo; y (5) apagando la autoidentificación para cierto tipo de archivo. En el ejemplo anterior, la autoidentificación se apaga para los archivos de los tipos MSTR. 3. Archivos de Salida del Dispositivo de Comparación El Dispositivo de Comparación 220 genera salidas a ser utilizadas por el Dispositivo de Generación 230. Además de generar la información para el Dispositivo de Generación 230, el Dispositivo de Comparación 220 también proporciona retroalimentación a la UI 210. La información generada por el Dispositivo de Comparación 220 a ser utilizada por otros componentes del sistema de generación de prueba para el Y2K, se describe en esta sección. a. Tablas de Uso del Campo Cada caso de un campo con fecha o prueba que el Dispositivo de Comparación 220 identifica, es registrado en una Tabla del Uso de un Campo con Fecha y una Tabla del Uso de un Campo de Prueba, respectivamente. La DFUT es utilizada por el Dispositivo de Generación 230 y SE 240 y la TFUT es utilizada sólo por el Dispositivo de Sustitución 240. (1) Tabla de Uso del Campo con Fecha Esta tabla lista todos los casos de los campos con fecha en cada uno de los casos de prueba de entrada. La tabla lista la fecha y la ubicación de cada uno de los campos con fecha. (2) Tabla de Uso del Campo de Prueba Esta tabla lista todos los casos de los campos de prueba en cada uno de los casos de prueba de entrada. La tabla lista la prueba y la ubicación de cada uno de los campos de prueba. b. Archivos de Salida del Dispositivo de Comparación - Tabla de Frecuencia de Restricciones Las restricciones de las fechas son una relación binaria de <, = o > entre dos tipos de fechas. Después de identificar todos los casos para cada tipo de fecha, el Dispositivo de Comparación 220 puede enlistar opcionalmente el número de casos de prueba de entrada para los cuales las relaciones <, = o > se mantiene para cualquier tipo de dos fechas. Lo siguiente es una tabla de frecuencia de restricciones de muestra.

DD DVA 12 0 0 DD FCD 12 0 0 DD _SYS 0 0 0 DVA FCD 12 0 0 DVA _SYS 0 0 0 FCD SYS 0 0 0 En el ejemplo anterior, DD, DVA, FCD y _SYS son los tipos de fecha. La 3era, 4ta y 5ta columnas respectivamente, dan cuentas de los casos de prueba de entrada, en los cuales el tipo de fecha en la columna es <, = y > que el tipo de fecha dado en la 2a columna. c. Archivos de Salida del Dispositivo de Comparación — Archivo de Registro Todas las advertencias encontradas durante la etapa de comparación, pueden registrarse en un archivo de registro. Si se encuentra una advertencia, el Dispositivo de Comparación 220 sacará el número de línea en donde ocurre la advertencia, e imprimirá el mensaje de advertencia en una nueva línea. Varios mensajes de advertencia pueden incluir: (1) Error al abrir un archivo (2) Campo faltante en una Regla (3) Desplazamiento ilegal en una Regla (4) No concordancia entre la entrada y el formato en una Regla de Fecha Desplazada (5) Constante de fecha autoidentificada y no tomada en cuenta 4. Procesamiento del Dispositivo de Comparación El procesamiento del Dispositivo de Comparación toma lugar en tres pasos. Los tres pasos se describen en detalle aquí. a. El Paso de Inicialización En el primer paso, el Dispositivo de Comparación 220 lee todas las reglas de comparación proporcionadas por el usuario. Durante la inicialización, el Dispositivo de Comparación 220 determina si las reglas de entrada proporcionadas por el usuario son válidas y cuando encuentra errores potenciales, expide una advertencia adecuada. b. El Paso del Procesamiento de las Reglas de Comparación En el segundo paso, el Dispositivo de Comparación 220 abre el archivo de catálogo de prueba y compara los casos de prueba en el orden en que se dan en el archivo de catálogo. c. El Paso de Inferencia de la Regla El Dispositivo de Comparación puede ajustarse opcionalmente para crear una Tabla de Frecuencia de Restricción. Esta Tabla de discute con detalle anteriormente.

C. Dispositivo de Generación (GE) Como se muestra en la Figura 4, el Dispositivo de Generación 230 toma tres clases de entradas: (1) restricciones de campo; (2) valores de campo; y (3) Tabla de Uso del Campo con Fecha. Estas entradas son utilizadas por uno de los algoritmos de generación para crear un conjunto de Versiones del Caso de Prueba ("TCV"), los cuales pueblan cada valor del campo requerido en cada campo, mientras que mantienen las restricciones proporcionadas por el usuario. 1. Entradas al GE a. Restricciones del Campo Estas son restricciones del campo proporcionadas por el usuario. Por ejemplo, si el caso de prueba de entrada es una forma de orden de compra con campos tales como la fecha de la orden y la fecha del envío, la fecha de la orden debe ser siempre anterior a la fecha de envío. Las restricciones del campo ("FC"), pueden ser de la siguiente forma: <Campo?> <Operador> <Campo2> donde CampoN : : = nombre del campo Operador : : = * <' | ' >' r = ' r /110 ' | ' +5 ' y a s í sucesivamente . Algunas entradas FC de ejemplo pueden incluir: "DUE_DATE < SHIP_DATE" "ORDER_INVENTORY > STOCK_INVENTORY" "Price(££)/110 Price($)" "ÍTEM COLOR = COLOR ÍTEM" Cada operador ( " <' I >' I =' I V110' ¡ ? +5' , etc.), s'e utiliza para inferir los valores permisibles en un campo, dado un valor en otro campo relacionado. Dado el valor "10,000" en el campo "ORDER_INVENTORY" , cualquier valor de menos de 10,000 es permisible en el campo "STOCK_INVENTORY" . Dado el valor de "990" en el campo " Price (fíD)" , el campo "Price($)" es permitido sólo para un valor de "9" . b. Valores del Campo Estos son los varios valores de los campos que se utilizarán para llenar los campos en los casos de prueba de salida. Incluyen las fechas con riesgo del Y2K. Los valores del Campo (FV), son de la siguiente forma: <Alfanumérico> <tipo> donde Alfanumérico una secuencia de caracteres alfanuméricos tipo ::= "requerido" | "opcional" Algunas entradas FV de ejemplo incluyen: "1999-12-31 requerido" "2000-04-15 opcional" "990 requerido" c. Tabla de Uso del Campo con Fecha La Tabla de Uso del Campo con Fecha se proporciona por el Dispositivo de Comparación 220. La tabla enlista todos los casos de campos con fecha y las ubicaciones de los mismos, dentro de cada caso de prueba de entrada. Los datos se organizan como una matriz de valores indexados por los nombres de los campos y los nombres del caso de prueba de entrada, como sigue: donde T = caso de prueba CampON = nombre del campo V(m,n) = nulo | <Value Used> <Position List> <Position List> : := <Position> I <Position> <Position List> m = índice del caso de prueba n ::= índice del campo Value_Used ::= secuencia alfanumérica Position ::= nombre del archivo, posición y longitud 2. Salidas del GE Versiones del Caso de Prueba El algoritmo de generación tomará las restricciones del campo ("FC"), los valores del campo ("FV") y las estructuras de los datos de la Tabla de Uso del Campo con Fecha, y crea estructuras de datos de las versiones del caso de prueba ("TCV"). La estructura TCV contiene una sola hilera para cada caso de prueba generado recientemente. Las columnas corresponden a los nombres de los campos de la estructura de uso del campo. Cada celda contiene el valor generado a ser utilizado durante la sustitución. El valor almacenado en cada celda se determina por uno-v de los algoritmos de generación de la siguiente sección. Los datos están organizados como una matriz de los valores indexados por los nombres de los campos lógicos y los nombres del caso de prueba lógico. donde TML ::= versión L del caso de Prueba M CampoN : : = nombre del campo V (m, n) ::= nulo|<Value> m ::= índice del caso de prueba n ::= índice del campo 1 ::= índice de la versión Valor ::= Secuencia alfanumérica 3. Algoritmo de Generación Los métodos de generación usarán uno de los varios posibles significados para colocar los valores de la estructura FV en los casos de prueba generados almacenados dentro de la estructura de las versiones del caso de prueba (TCV) . El objetivo de cada método de generación es asegurar que todos los valores de campo requeridos se prueben por cada campo de la estructura de la DFUT. Este objetivo es satisfecho creando versiones nuevas de los casos de prueba que contienen los valores de la estructura FV. Además, las restricciones del campo FC se utilizan para asegurar que la relación entre los campos se mantiene en las versiones generadas de cada caso de prueba. El progreso hacia la obtención' del objetivo, se mide determinando el alcance de los valores de campo utilizados en los casos de prueba generados, contra los campos de la DFUT. donde FVP ::= valor del campo requerido Cam?oN : := nombre del campo V(p,n) ::= nulo|.caso de prueba p ::= índice del valor del campo n ::= índice del campo Por ejemplo, suponer que: a. Tres valores de campo requeridos son "2000-01- 01", "2000-02-29" y "2000-03-01" . b. Tres campos para generación son "ORDER", "SHIP" y "DUE" . c. Dos restricciones son "ORDER < SHIP" y "SHIP < DUE" En este ejemplo, la siguiente matriz muestra cómo cuatro versiones de un solo caso de prueba (Ti, T2, T3 y T4) , cubren ocho de las nueve combinaciones requeridas de los valores de campo y los nombres de campo.

La siguiente tabla enlista las cuatro versiones del caso de prueba T, que proporciona el alcance en la matriz anterior.

Nota*: Después de crear estas cuatro versiones del caso de prueba, el método de generación crea el quinto caso de prueba final, para cubrir el valor requerido de "2000-01-01" en el campo "DUE", que corresponde al " *" indicado en la tabla anterior. Nota**: Nótese que este valor de campo se crea para satisfacer las restricciones del campo. Los métodos de generación comparten el mismo objetivo, pero difieren en cómo se obtiene el objetivo cuando se múltiples casos de prueba utilizan los mismos campos. El primer método de generación, el Método Exhaustivo, asegura que cada valor del FV se coloque en cada campo de todos los casos de prueba. Este método trata cada caso de prueba independientemente, y por lo tanto, el número total mayor de versiones a través de todos los casos de prueba, se genera. El segundo y tercer métodos de generación (Primer Método Comprimido) , (Método Total Comprimido) , aseguran que cada valor de campo se pruebe en al menos un caso de prueba. Estos dos métodos ofrecen una forma de generación "comprimida", debido a que reutilizan el alcance de los valores de campo a través de los casos de prueba. Se generarán menos casos de prueba utilizando el segundo o tercer método de generación. Nótese que no todos los casos de prueba originales necesariamente se incluirán en la salida final. El segundo y tercer métodos difieren en el orden en el que crean las versiones múltiples de los casos de prueba. El segundo caso creará tantas versiones del primer caso de prueba para probar totalmente todos los valores de campo para cada campo, antes de intentar generar nuevas versiones de cualquier caso de prueba de entrada. El tercer método creará una versión de cada caso de prueba de entrada, antes de crear cualesquier versiones del caso de prueba adicionales. Este proceso continúa realizando un ciclo a través de la lista de los casos de entrada. El cuarto método de generación (Método Comprimido) , generalmente sigue los mismos pasos de procesamiento que el tercer método, pero asegura que todos los casos de prueba de entrada se incluyan en los casos de prueba de salida.

D. DISPOSITIVO DE SUSTITUCIÓN ("SE") Como se muestra en la Figura 4, el Dispositivo de Sustitución (SE) toma la salida del Dispositivo de Comparación 220 (Tabla de Uso del Campo de Datos y Tabla de Uso del Campo de Prueba, proporcionando las ubicaciones de los campos) y la salida del Dispositivo de Generación 230 (Versiones del Caso de Prueba que proporcionan el tamaño y contenido de los casos de prueba manufacturados) . Esta información se basa para crear las copias de los casos de prueba de entrada que contienen un reemplazo de los valores del campo de entrada con los valores de campo generados que incluyen las fechas con riesgo del Y2K. adicionalmente, el SE 240 reemplazará opcionalmente otros valores de campo, tales como los valores de prueba, únicamente a través de los casos de prueba. Esta característica se utilizará cuando un campo dentro de un caso de prueba contiene valores que deben ser únicos para cada caso de prueba. Por ejemplo, el nombre del cliente en un punto de sistema de venta o número de parte en un sistema de inventario, tiene que ser diferente para cada caso de salida de prueba.

Entradas a. Reglas de Sustitución Las Reglas de Sustitución (SR) son de la siguiente forma : <nombre> <tipo de datos> <modificador> <lista de valor> donde nombre ::= etiqueta asignada a cada tipo de campo encontrado por PE 220 tipo de datos : : =" INTEGER" |"TEXT" , etc. modificador INCREMENT" " CYCLE" lista de valor ::= <value> | <value> ,' <value list> valor : : - caracteres alfanuméricos Algunas entradas SR de ejemplo incluirían: (1) "CustomerName TEXT CYCLE Jones, Smith, Zeller" (2) "PartNumber INTEGER INCREMENT 1000" (3) "Blues TEXT CYCLE Baby, Stell, Light, Navy" b. Tabla de Uso del Campo de Datos c. Tabla de Uso del Campo de Prueba d. Versiones del Caso de Prueba 2. Salidas Los casos de prueba de salida pueden crearse en estructuras de directorio, los cuales son copias especulares múltiples del original. La Figura 5 ilustra este proceso de copiado. Cada uno de los casos de prueba de entrada ( i a TN) , se copia el número de veces apropiado (N' a N" veces, por ejemplo) de acuerdo a un algoritmo de generación seleccionado. Otra opción para producir los casos de prueba de salida es utilizar el "Modo de Salida Parametrizado" . Aquí, en lugar de generar diferentes archivos para diferentes versiones de un caso prueba, los usuarios pueden decidir generar una versión parametrizada del caso de prueba. Bajo esta opción el sistema genera 1) un procedimiento parametrizado (valores codificados de manera no flexible, apropiados, etc., son reemplazados por variables cuyos valores pueden llamarse de un archivo -de datos) ; 2) una rutina de accionamiento para el procedimiento; y 3) un archivo de datos que contiene las entradas para los parámetros del procedimiento. Se espera que la rutina de accionamiento abra el archivo de datos, y para cada hilera de datos en el archivo de datos, requiere al procedimiento con los valores de los parámetros sustituidos con los datos actuales. Este enfoque resulta en la reducción de espacio de almacenamiento y también mejora el mantenimiento de los casos de prueba. 3. Algoritmo de Sustitución El SE 240 lleva a cabo el paso de sustitución en un proceso de tres etapas: a. Hace copias de los casos de prueba de entrada como se requiera. Ver la Figura 5. b. Reemplazar los valores de los campos de entrada con valores generados de acuerdo con las TCV y la Tabla de Uso del Campo con Fecha. c. Reemplazar los valores de los campos originales con los valores de sustitución de acuerdo con la SR y la Tabla de Uso del Campo de Prueba.

E. SIMULADOR DE SALIDA ("OS") En una implementación de la invención, el sistema de la presente invención genera una salida esperada para los casos de prueba de acuerdo con el Y2K como sigue. Para cada caso de prueba de salida, digamos "T", el sistema crea dos casos de prueba intermediario, digamos "II" y "12". Un caso de prueba intermediario se obtiene sustrayendo n*28 años de cada ocurrencia de fecha en T, donde n es un entero mayor que 0, tal que después de la sustracción, todas las fechas están en el siglo 20. "n" debe ser diferente de II y de 12. Típicamente, n=l ó 2. II y 12 se ejecutan en un sistema no renovado y las salidas 01 y 02 son capturadas. El caso de prueba de salida se ejecuta en el sistema renovado y la s-alida O se captura del mismo. Cuando se hace la prueba de acuerdo con el Y2K, O (salida de T) , debe concordar con 01 y 02 en los lugares donde 01 y 02 concuerdan y diferir donde 01 y 02 difieren. Si éste no es el caso, entonces el caso de salida T no ha cubierto un "error" del Y2K potencial, en el sistema renovado. Aunque sólo el método n*28 se discute aquí, cualquier metodología de prueba adecuada puede utilizarse. Por ejemplo, las salidas del sistema basadas en los casos de prueba de salida de la presente invención, pueden compararse con otras salidas del sistema que se sabe son correctas.

F. CAPACIDADES ADICIONALES Aunque el sistema y método descritos en la presente son para la creación de casos de prueba de acuerdo con el Y2K, el sistema y método de la presente invención son aplicables a cualquier situación, donde se hicieron cambios masivos después de un patrón o regla de sustitución consistente, a un código de origen. Los ejemplos de tales cambios son casos donde: un tipo de parámetro de entrada se cambia de numérico a alfanumérico; las unidades utilizadas para especificar las entradas al sistema se cambian de libras a kg; o GTM a EST, y así sucesivamente; y los números de teléfono se cambian de números de siete dígitos a diez dígitos. Los sistemas y método consistentes con la presente invención, pueden utilizarse para probar tales cambios fácil y rápidamente, empleando un conjunto de valores "con riesgo" apropiados a ser utilizados cuando se enumeran los escenarios de casos de prueba de salida. Será evidente a aquéllos con experiencia en la técnica, que varias modificaciones y variaciones pueden hacerse en los sistemas y métodos de la presente invención sin apartarse del alcance y espíritu de la invención. Otras implementaciones de la invención serán evidentes a aquéllos con experiencia en la técnica, a partir de la consideración de la especificación y la práctica de la invención descrita en la presente. Se pretende que la especificación y los ejemplos se consideren como ejemplares solamente, con el alcance verdadero y espíritu de la invención indicados por las siguientes reivindicaciones. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la presente invención, es el que resulta claro de la descripción a la que la misma se refiere.

Claims (39)

REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones.

1. Un método para generar casos de prueba para utilizarse en la prueba de un sistema de acuerdo con el Año 2000, caracterizado porque comprende los pasos de: proporcionar a un procesador de datos uno o más casos de prueba de entrada que corresponden al sistema; identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de los casos de prueba de entrada, utilizando el procesador de datos; y generar selectivamente de acuerdo con un segundo conjunto de criterios predeterminados, uno o más campos casos de prueba de salida, utilizando el procesador de datos; donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de prueba de salida incluye una fecha con riesgo de un conjunto de fechas con riesgo.

2. El método de conformidad con la reivindicación 1, caracterizado porque el paso de proporcionar incluye : proporcionar uno o más casos de prueba de entrada al procesador de datos a través de la Red Mundial (World Wide Web) .

3. El método de conformidad con la reivindicación 1, caracterizado porque en el paso de identificación, el primer conjunto de criterios predeterminados incluye reglas que identifican la fecha, automáticas, provistas por el procesador de datos.

4. El método de conformidad con la reivindicación 1, caracterizado porque el paso de identificación incluye: generar reportes de cualquier error potencial detectado durante el paso de identificación.

5. El método de conformidad con la reivindicación 1, caracterizado porque en el paso ' de identificación, el primer conjunto de criterios incluye reglas proporcionadas por el usuario.

6. El método de conformidad con la reivindicación 5, caracterizado porque comprende, además: determinar si las reglas proporcionadas por el usuario son potencialmente incorrectas.

7. El método de conformidad con la reivindicación 5, caracterizado porque comprende, además: determinar si las reglas proporcionadas por el usuario son potencialmente incompletas .

8. El método de conformidad con la reivindicación 5, caracterizado porque comprende, además: identificar las reglas proporcionadas por el usuario que son potencialmente incorrectas o incompletas; y permitir la corrección de algunas o todas las reglas provistas por el usuario potencialmente incorrectas o incompletas .

9. El método de conformidad con la reivindicación 1, caracterizado porque el paso de generar selectivamente incluye generar uno o más casos de prueba de salida en uno o más conjuntos de casos de prueba de salida, donde el segundo conjunto de criterios predeterminados, asegura que cada conjunto de casos de prueba de salida corresponda con uno o más casos de prueba de entrada.

10. El método de conformidad con la reivindicación 9, caracterizado porque en el paso de generar selectivamente, el segundo conjunto de criterios predeterminados asegura que cada fecha con riesgo del conjunto de fechas con riesgo, se coloque al menos una vez en cada campo dependiente de la fecha en cada conjunto de casos de prueba de salida.

11. El método de conformidad con la reivindicación 9, caracterizado porque en el paso de generar selectivamente, el segundo conjunto de criterios predeterminados asegura que cada fecha con riesgo del conjunto de fechas con riesgo, se coloque al menos una vez en cada campo dependiente de la fecha en los casos de prueba de salida.

12. El método de conformidad con la reivindicación 9, caracterizado porque en el paso de generar selectivamente, el segundo conjunto de criterios predeterminados asegura que cada caso de prueba de entrada tenga al menos un conjunto correspondiente de casos de prueba de salida y que cada fecha con riesgo del conjunto de fechas con riesgo, se coloque al menos una vez en cada campo dependiente de la fecha en los casos de prueba de salida.

13. El método de conformidad con la reivindicación 1, caracterizado porque en el paso de generar selectivamente, el segundo conjunto de criterios predeterminados asegura que los casos de prueba de salida se conformen con las restricciones proporcionadas por el usuario.

14. El método de conformidad con la reivindicación 1, caracterizado porque comprende, además: proporcionar uno o más conjuntos de casos de prueba de salida a través de la Red Mundial (World Wide Web) .

15. Un método para generar casos de prueba para utilizarse en la prueba de un sistema de acuerdo con el Año 2000, caracterizado porque comprende los pasos de: proporcionar a un procesador de datos uno o más casos de prueba de entrada que corresponden al sistema; identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de los casos de prueba de entrada, utilizando el procesador de datos; generar selectivamente de acuerdo con un segundo conjunto de criterios predeterminados, uno o más campos casos de prueba de salida, utilizando el procesador de datos; donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de prueba de salida incluye una fecha con riesgo de un conjunto de fechas con riesgo; y determinar si el sistema a prueba está de acuerdo con el Año 2000, ejecutando los casos de prueba de salida en el sistema a prueba.

16. El método de conformidad con la reivindicación 15, donde el paso de determinar incluye: proporcionar un primer conjunto de salidas del sistema, el primer conjunto de salidas del sistema se generan ejecutando los casos de prueba de salida en el sistema a prueba; proporcionar un segundo conjunto de salidas del sistema que se sabe son correctas, y comparar el primer y segundo conjuntos de salidas del sistema, para detectar cualesquier errores potenciales en el sistema a prueba.

17. El método de conformidad con la reivindicación 15, donde el paso de determinar incluye: proporcionar un primer conjunto de salidas del sistema, el primer conjunto de salidas del sistema se generan ejecutando un primer conjunto de casos de prueba, cuyas fechas pertenecen todas al siglo 20; proporcionar un segundo conjunto de salidas del sistema, el segundo conjunto de salidas del sistema se genera ejecutando un segundo conjunto de casos de prueba, diferente, cuyas fechas pertenecen todas al siglo 20; proporcionar un tercer conjunto de salidas del sistema, el tercer conjunto de salidas del sistema se genera ejecutando los casos de prueba de salida; comparar el primer y segundo conjuntos de salidas del sistema; y determinar si el tercer conjunto de salidas del sistema concuerdan y difieren con el primer conjunto de salidas, donde el primer y segundo conjuntos de salidas del sistema concuerdan y difieren.

18. El método de conformidad con la reivindicación 17, donde el primer y segundo conjuntos de casos de prueba se generan de los casos de prueba de salida, sustrayendo n*28 años de cada ocurrencia de fecha en los campos dependientes de la fecha o de los casos de prueba de salida, donde n es un entero mayor que 0 y n es diferente para el primer y segundo conjuntos de casos de prueba.

19. Un método para generar casos de prueba para utilizarse en la prueba de un sistema de acuerdo con el Año 2000, caracterizado porque comprende los pasos, realizados por un procesador de datos, de: identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de uno o más casos de prueba de entrada, que corresponden al sistema a prueba; y generar selectivamente de acuerdo con un segundo conjunto de criterios predeterminados, versiones para etrizadas de los casos de prueba de salida, donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de prueba de salida, incluye una fecha con riesgo de un conjunto de fechas con riesgo, y donde las versiones parametrizadas, las versiones son más compactas que los casos de prueba de salida, pueden utilizarse para generar casos de prueba de salida.

20. Un método para generar casos de prueba para una prueba de acuerdo a la conversión de un sistema a prueba, caracterizado porque comprende los pasos de: proporcionar a un procesador de datos uno o más casos de prueba de entrada que corresponden al sistema a prueba; identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la conversión, en cada uno de los casos de prueba de entrada, utilizando el procesador de datos; y generar selectivamente de acuerdo con un segundo conjunto de criterios predeterminados, uno o más campos casos de prueba de salida, utilizando el procesador de datos; donde al menos uno de los campos dependientes de la conversión en cada uno de los casos de prueba de salida incluye una conversión con riesgo de un conjunto de valores de conversión con riesgo.

21. El método de conformidad con la reivindicación 20, caracterizado porque la conversión involucra unidades de tipo de cambio.

22. El método de conformidad con la reivindicación 20, caracterizado porque la conversión involucra unidades de tiempo.

23. El método de conformidad con la reivindicación 20, caracterizado porque la conversión involucra unidades de medición.

24. Un sistema para generar casos de prueba para probar un sistema de acuerdo con el Año 2000, caracterizado porque comprende: una interfaz para recibir uno o más casos de prueba de entrada que corresponden al sistema a prueba; un dispositivo de comparación para identificar de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de los casos de prueba de entrada; y un componente de generación, configurado para generar selectivamente, de acuerdo con un segundo conjunto de criterios predeterminados, uno o más casos de prueba de salida, donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de prueba de salida, incluye una fecha con riesgo de un conjunto de fechas con riesgo.

25. El sistema de conformidad con la reivindicación 24, caracterizado porque el componente de generación está configurado para generar selectivamente, uno o más casos de prueba de salida, en uno o más conjuntos de casos de salida, donde el segundo conjunto de criterios predeterminados asegura que cada conjunto de casos de prueba de salida, corresponde a uno o más de los casos de prueba de entrada.

26. El sistema de conformidad con la reivindicación 25, caracterizado porque el segundo conjunto de criterios predeterminados asegura que cada fecha con riesgo del conjunto de fechas con riesgo se coloque al menos una vez en cada conjunto de casos de prueba de salida.

27. El sistema de conformidad con la reivindicación 25, caracterizado porque el segundo conjunto de criterios predeterminados asegura que cada fecha con riesgo del conjunto de fechas con riesgo se coloque al menos una vez en cada campo dependiente de la fecha en los casos de prueba de salida.

28. El sistema de conformidad con la reivindicación 25, caracterizado porque el segundo conjunto de criterios predeterminados asegura que cada prueba de entrada tenga al menos un conjunto correspondiente de casos de prueba de salida, y que cada fecha con riesgo del conjunto de fechas con riesgo se coloque al menos una vez en cada campo dependiente de la fecha en los casos de prueba de salida.

29. Un sistema para generar casos de prueba para probar un sistema de acuerdo con el Año 2000, caracterizado-porqué comprende: una interfaz para recibir uno o más casos de prueba de entrada; un dispositivo de comparación para identificar de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno del uno o más casos de prueba de entrada; un componente de generación, configurado para generar selectivamente, de acuerdo con un segundo conjunto de criterios predeterminados, uno o más casos de prueba de salida, donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de prueba de salida, incluye una fecha con riesgo de un conjunto de fechas con riesgo; y un componente de prueba configurado para determinar si el sistema a prueba está de acuerdo con el año 2000.

30. El sistema de conformidad con la reivindicación 29, caracterizado porque el componente de prueba comprende: medios para recibir un primer conjunto de salidas del sistema, el primer conjunto de salidas del sistema se genera ejecutando un primer conjunto de casos de prueba, cuyas fecha pertenecen todas al siglo 20; medios para recibir un segundo conjunto de salidas del sistema, el segundo conjunto de salidas del sistema se genera ejecutando un segundo conjunto de casos de prueba, diferente, cuyas fechas pertenecen todas al siglo 20; donde el primer y segundo conjuntos de casos de prueba se generan de los casos de prueba, de salida, sustrayendo n*28 años de cada ocurrencia de fecha en los casos de prueba de salida, donde n es un entero mayor que 0 y n es diferente del primer y segundo casos de prueba; medios para recibir un tercer conjunto de salidas del sistema, el tercer conjunto de salidas del sistema se genera ejecutando los casos de prueba de salida; medios para comparar el primer y segundo conjuntos de salidas del sistema; y medios para determinar si el tercer conjunto de salidas del sistema concuerdan y difieren con el primer y segundo conjuntos de salidas, donde el primer y segundo conjuntos de salidas del sistema concuerdan y difieren.

31. Un sistema para generar casos para probar un sistema, caracterizado porque comprende: un dispositivo de comparación para identificar de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de uno o más casos de prueba de entrada; y un componente de generación, configurado para generar selectivamente, de acuerdo con un segundo conjunto de criterios predeterminados, versiones parametrizadas de los casos de prueba de salida, donde al menos uno de los campos dependientes de la fecha en cada versión parametrizada del caso de prueba de salida, incluye una fecha con riesgo de un conjunto de fechas con riesgo, y donde las versiones parametrizadas, y las versiones son más compactas que los casos de prueba de salida, pueden utilizarse para generar casos de prueba de salida.

32. Un medio legible por computadora, capaz de configurar un procesador de datos para que genere casos de prueba para probar un sistema de acuerdo con el Año 2000, el medio comprende un código de programa para hacer que el procesador realice los pasos de: identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de uno o más casos de prueba de entrada, que corresponden al sistema a prueba; y generar selectivamente de acuerdo con un segundo conjunto de criterios predeterminados, uno o más casos de prueba de salida; donde al menos uno de los campos dependientes de la fecha en cada uno de los casos de prueba de salida incluye una fecha con riesgo de un conjunto de fechas con riesgo.

33. El medio legible por computadora de conformidad con la reivindicación 32, caracterizado porque el paso de generar selectivamente, incluye generar uno o más casos de prueba de salida en uno o más conjuntos de casos de prueba de salida, donde el segundo conjunto de criterios predeterminados, asegura que cada conjunto de casos de prueba de salida corresponda a uno o más casos de prueba de entrada.

34. El medio legible por computadora de conformidad con la reivindicación 33, caracterizado porque en el paso de generar selectivamente, el segundo conjunto de criterios predeterminados, asegura que cada fecha con riesgo del conjunto de fechas con riesgo, se coloque al menos una vez en cada campo dependiente de la fecha, en cada conjunto de casos de prueba de salida.

35. El medio legible por computadora de conformidad con la reivindicación 33, caracterizado porque en el paso de generar selectivamente, el segundo conjunto de criterios predeterminados, asegura que cada fecha con riesgo del conjunto de fechas con riesgo, se coloque al menos una vez en cada campo dependiente de la fecha, en cada conjunto de casos de prueba de salida.

36. El medio legible por computadora de conformidad con la reivindicación 33, caracterizado porque en el paso de generar selectivamente, el segundo conjunto de criterios predeterminados, asegura que cada prueba de entrada tenga al menos un conjunto correspondiente de casos de prueba de salida y que cada fecha con riesgo del conjunto de fechas con riesgo, se coloque al menos una vez en cada campo dependiente de la fecha, en cada conjunto de casos de prueba de salida.

37. Un medio legible por computadora, capaz de configurar un procesador de datos para generar casos de prueba para probar un sistema de acuerdo con el Año 2000, caracterizado porque el medio comprende un código de programa que hace que el procesador realice los pasos de: proporcionar al procesador de datos uno o más casos de prueba de entrada; identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de los casos de prueba de entrada; generar selectivamente, de acuerdo con un segundo conjunto de criterios predeterminados, uño o más casos de prueba de salida, donde al menos uno de los campos dependientes de la fecha en cada caso de prueba de salida, incluye una fecha con riesgo de un conjunto de fechas con riesgo; y determinar si el sistema a prueba está de acuerdo con el año 2000.

38. El medio legible por computadora de conformidad con la reivindicación 37, caracterizado porque el paso de determinar comprende: proporcionar un primer conjunto de salidas del sistema, el primer conjunto de salidas del sistema se genera ejecutando un primer conjunto de casos de prueba, en el sistema a prueba, cuyas fechas pertenecen todas al siglo 20; proporcionar un segundo conjunto de salidas del sistema, el segundo conjunto de salidas del sistema se genera ejecutando un segundo conjunto de casos de prueba, diferente, en el sistema a prueba, cuyas fechas pertenecen todas al siglo 20; donde el primer y segundo conjuntos de casos de prueba se generan de los casos de prueba de salida, sustrayendo n*28 años de cada ocurrencia de fecha en los casos de prueba de salida, donde n es un entero mayor que 0 y n es diferente del primer y segundo casos de prueba; proporcionar un tercer conj nto de salidas del sistema, el tercer conjunto de salidas del sistema se genera ejecutando los casos de prueba de salida en el sistema a prueba; comparar el primer y segundo conjuntos de salidas del sistema; y determinar si el tercer conjunto de salidas del sistema concuerda y difiere con el primer y segundo conjuntos de salidas, donde el primer y segundo conjuntos de salidas del sistema concuerdan y difieren.

39. Un medio legible por computadora capaz de configurar un procesador de datos para generar casos de prueba para probar un sistema, de acuerdo al Año 2000, caracterizado porque el medio comprende un código de programa para hacer que el procesador de datos realice los pasos de: identificar, de acuerdo con un primer conjunto de criterios predeterminados, uno o más campos dependientes de la fecha, en cada uno de los casos de prueba de entrada; y generar selectivamente, de acuerdo con un segundo conjunto de criterios predeterminados, versiones parametrizadas de los casos de prueba de salida, en uno o más conjuntos de versiones parametri?adas, de uno o más casos de prueba de salida, donde cada conjunto de versiones parametrizadas de los casos de prueba 'de salida, corresponde a uno de los casos de prueba de entrada, donde al menos uno de los campos dependientes de la fecha en cada caso de prueba de salida, incluye una fecha con riesgo de un conjunto de fechas con riesgo, y donde las versiones parametrizadas, las versiones son más compactas que los casos de prueba de salida, pueden utilizarse para generar casos de prueba de salida .