METHODE POUR TESTER UN PROGRAMME
La présente invention se rapporte à une méthode pour tester au-moins un programme qui est normalement exécuté suivant un calendrier.
Lorsque le temps d'exécution du programme est long, le temps requis pour tester le programme a une longueur correspondante puisque des erreurs de programme peuvent apparaître même près de la fin du test.
Un but de la présente invention est de fournir une méthode du type mentionné ci-dessus, mais qui permet un test relativement rapide du programme.
Selon l'invention, ce but est atteint par le fait que la méthode consiste à exécuter ledit programme suivant un second calendrier fonction dudit calendrier mentionné premièrement.
Une autre caractéristique de la présente méthode est que ledit second calendrier est proportionnel au et exécuté plus rapidement que ledit premier calendrier.
Parce que le temps d'exécution du programme peut donc être considérablement réduit, même des erreurs de programme se produisant près de la fin de ce test apparaissent relativement tôt.
Encore une autre caractéristique de la présente méthode est qu'elle consiste à exécuter ledit programme suivant ledit second calendrier avant de l'exécuter suivant ledit premier calendrier.
De cette façon, les erreurs apparaissant pendant l'execution du test peuvent être corrigées avant que le programme soit exécuté normalement.
Encore une autre propriété caractéristique de la présente méthode est qu'elle consiste à tester une pluralité des dits programmes en les exécutant suivant des seconds calendriers correspondants.
De cette façon, des conflits entre des programmes exécutés simultannément sont détectés très tôt.
Les buts et caractéristiques de l'invention décrits ci-dessus ainsi que d'autres et la manière de les obtenir deviendront plus clairs et l'invention elle-même sera mieux comprise, en se référant à la description suivante d'un exemple de réalisation de l'invention pris en relation avec les dessins qui l'accompagnent :
Fig. 1 est une vue schématique d'un système de télécommunication utilisant une méthode de test selon l'invention; Fig. 2 est un calendrier montrant des programmes à tester par cette méthode; Fig. 3 est un organigramme illustrant diverses étapes de la méthode de test.
La méthode de test de programme dite Test-Rapide décrite ci-après est utilisée dans un système de télécommunication pour tester divers programmes qui sont contenus dans une mémoire, par exemple une unité de disques 1 montrée à la Fig. 1, couplée à un central de télécommunication 2 pourvu d'une pluralité de lignes d'abonnés tels que 4 et d'une pluralité de jonctions telles que 5 formant un certain nombre de voies. Ces programmes peuvent être appelés à n'importe quel moment par un opérateur via son pupitre ou tout autre terminal 3, par exemple un équipement de télétype, couplé au central 2. Lorsqu'un tel programme est appelé par un opérateur afin de réaliser une mesure ou une observation particulière, l'opérateur introduit des paramètres dans le programme via des instructions ou commandes.
Ces paramètres indiquent ce qui doit être mesuré ou observé et quand celà doit être effectué. Lorsque le programme est pourvu de ces paramètres et activé par l'opérateur, il devient un "job".
Trois types de programmes sont considérés : un programme d'observation de ligne d'abonné, un programme de mesure de trafic de voie et un programme pour désactiver des jobs sélectionnés.
Plus en détail, les commandes et paramètres d'entrée pour le programme d'observation de ligne d'abonné sont donnés dans le TABLEAU 1 et sont comme suit: <EMI ID=1.1> de la ligne d'abonné pour laquelle l'observation doit être faite est entrée après l'étiquette IDENT-ABONNE;
- la date et l'heure de début d'une période d'observation exprimées en "année & mois & jour" et "heure : minute" respectivement sont entrées après l'étiquette DEBUT-PERIODEn, où n est le numéro de la période;
- la date et l'heure de fin d'une période d'observation exprimées en "année & mois & jour" et "heure : minute" respectivement sont entrées après l'étiquette FIN-PERIODEn;
- l'identité du "dispositif-de-sortie" sur lequel le rapport d'observation doit être généré est entrée après l'étiquette DISPOSITIF-SORTIE.
Il est à noter que si plus d'une observation est requise, par exemple PERIODE1, PERIODE2, les paramètres de début et de fin sont donnés pour chacunes de ces périodes requises.
<EMI ID=2.1>
<EMI ID=3.1>
Les commandes pour le programme de mesure de trafic de voie sont donnés dans le TABLEAU 2 et sont comme suit : <EMI ID=4.1> numéros des voies pour lesquelles les mesures doivent être effectuées sont entrées après l'étiquette IDENT-VOIE;
- la date de début de la mesure exprimée en "année & mois & jour" est entrée après l'étiquette DATE-DEBUT;
- l'heure du début de la mesure exprimée en "heure :
minute" est entrée après l'étiquette HEURE-DEBUT;
- l'heure de la fin de la mesure exprimée en "heure :
minute" est entrée après l'étiquette HEURE-FIN;
- l'identité du "dispositif-de-sortie" sur lequel les résultats des mesures doivent être imprimés est entrée après l'étiquette DISPOSITIF-SORTIE.
<EMI ID=5.1>
Il est à noter que le programme de mesure de trafic de voie se distingue du programme d'observation de ligne d'abonné par le fait que le premier est automatiquement répété chaque jour durant la même période définie par l'HEURE-DEBUT et l'HEURE-FIN et commence à la DATE-DEBUT, alors que le second est exécuté uniquement pendant la(les) PERIODE(s) définie(s) par les paramètres d'entrée correspondants. Cependant, un programme de mesure de trafic de voie peut contenir une commande DATE-ARRET indiquant la date et l'heure de la fin de ce job. Une autre manière d'arrêter le programme de mesure de trafic de voie est d'utiliser le programme DESACTIVATION-DE-JOB pour désactiver des mesures sélectionnées et qui est décrit ci-dessous.
Les commandes du programme de désactivation de job sont montrées dans le TABLEAU 3 et sont comme suit :
- le numéro de séquence ou "numéro-de-job" du job qui doit être désactivé est entré après l'étiquette IDENT-JOB;
- la date de désactivation exprimée en "année & mois & jour" est entrée après l'étiquette DATE-ARRET.
Le numéro de job est un numéro qui est automatiquement attribué à tout job activé par un opérateur. Il est à noter que la DATE-ARRET est optionnelle et que lorsqu'aucune DATE-ARRET n'est donnée la désactivation est immédiatement effective.
<EMI ID=6.1>
Un test de possiblité d'exécution ou de faisabilité appelé Test-Rapide est effectué pour chaque nouveau job et consiste à tester immédiatement les limitations du central, les conflicts possibles avec d'autres jobs et la mémoire disponible qui devra être partagée avec d'autres jobs.
Ce test sera mieux compris par la description suivante d'un exemple donné dans les TABLEAUX 4 à 11 et illustré par les Figs. 2 et 3. Pour cet exemple les limitations du central sont supposées être les suivantes:
- seules les voies numérotées de 1 à 15 existent;
- plusieurs jobs d'observation de ligne d'abonné peuvent être exécutés simultannément, mais pas plus d'une ligne d'abonné ne peut être observée au même instant;
- le nombre maximum de jobs en cours d'exécution est 3;
- le temps d'exécution du Test-Rapide est limité à un maximum de 5 minutes.
Dans l'exemple, le 10 Juillet 1984 à 12h30 un opérateur appelle un programme d'observation de ligne d'abonné afin d'observer la ligne d'abonné ayant le numéro 4819 durant une première période PERIODE1 s'étendant du 17 Juillet 1984 à 11h00 (1984 & 7 & 17,
11 : 00) au 18 Juillet 1984 à 14h00 (1984 & 7 & 18,
14 : 00) et durant une seconde période PERIODE2 s'étendant du 20 Juillet 1984 à 14h00 (1984 & 7 & 20,
14 : 00) au 21 Juillet 1984 à 6h00 (1984 & 7 & 21,
06 : 00). Ces valeurs sont donc entrées par l'opérateur et le numéro de séquence 1 est attribué au job correspondant, c'est-à-dire JOB1. Le dispositif de sortie pour JOB1 est l'équipement de télétype numéro 2 TTY2.
<EMI ID=7.1>
Le calendrier du JOB1 est représenté schématiquement à la Fig. 2 où les valeurs sur l'axe des temps t sont les jours de calendrier du mois de Juillet
1984. Plus en détail, la date d'activation du JOB1 est représentée par SI et les périodes de travail PERIODE1 et PERIODE2 sont représentées par J1A et J1B respectivement.
Se référant à l'organigramme montré à la Fig. 3, l'appel d'un programme y est indiqué par un rectangle A et un rectangle B représente l'entrée des paramètres dans ce programme. Lorsque cette opération est terminée un test C est fait afin de savoir si d'autres jobs sont déjà cours d'exécution. Comme JOB1 est le premier job la réponse au test C est non, c'est-à-dire N. le Test-Rapide est alors exécuté sur JOB1 comme représenté par le rectangle D dans l'organigramme. Ce test consiste à vérifier la possibilité d'exécution du job en simulant son exécution réelle, c'est-à-dire en exécutant ce job avec une horloge qui est beaucoup plus rapide que l'horloge du temps réel. Le calendrier simulé pour ce job est donc parcouru en quelques minutes au lieu de, par exemple, plusieurs heures ou même plusieurs jours pour le calendrier réel.
En d'autres termes, le job est exécuté suivant un calendrier fonction du calendrier réel de ce job. Pendant ce test toutes les opérations d'entrée et de sortie du job réel sont simulées de façon à ce qu'aucun temps ne soit perdu à attendre des réponses ou des entrées possibles du central ou de ses périphériques. Le test est terminé lorsque l'horloge rapide atteint la dernière date de fin du job qui est testé ou lorsque le temps d'exécution maximum attribué au test est dépassé.
Un rapport tel que celui montré dans le TABLEAU 5 est généré à la fin du Test-Rapide. Ce rapport, représenté par le rectangle E dans l'organigramme de la Fig. 3, contient de brèves informations sur le job testé et les résultats du test. Plus en détail, la première ligne de ce rapport donne le numéro de séquence du job JOB1 et est suivie par la date et l'heure du test exprimées en année 1984, mois 7, jour 10, heure 12 et minute 32. La différence entre l'HEURE de FIN DE TEST et l'HEURE de DEBUT DE TEST indique que ce test ne dure qu'environ une minute MM=31 - MM=30. Il n'y a pas d'erreurs (NBR D'ERREURS = 0), ni d'avertissements (NBR D'AVERTISSEMENTS = 0) de sorte que la RAISON DE la FIN de ce job est que le calendrier simulé du JOB REQUERANT LE TEST a été entièrement parcouru ou EST TERMINE.
Le fait qu'il n'y a pas d'erreurs, ni d'avertissements donne une première indication sur la possibilité d'exécuter le job. Celà signifie que la ligne d'abonné ayant le numéro 4819 existe, que le dispositif de sortie TTY2 est disponible et qu'il y a suffisamment de mémoire pour exécuter ce job. La dernière ligne du rapport du Test-Rapide fourni, pour tous les JOBS PARTICIPANTS A CE TEST, c'est-à-dire uniquement JOB1 dans ce cas-ci, les informations suivantes :
- le TYPE de job : ABNN signifie une observation de ligne d'abonné;
- l'identification du JOB ou numéro de séquence du job 1;
- l'ETAT de ce job à la fin du test : le job était TERMINE le 1984 & 7 & 21 à 6h00 qui est la dernière date et heure de fin de ce job.
TABLEAU 5
RAPPORT DE TEST-RAPIDE :
JOB1 ; 1984 & 7 & 10 , 12 : 32
HEURE-DEBUT DE TEST = 1984 & 7 & 10 , HH=12 : MM=30 HEURE-FIN DE TEST 1984 & 7 & 10 , HH=12 : MM=31 RAISON DE FIN = LE JOB REQUERANT LE TEST EST TERMINE
NBR D'ERREURS 0
NBR D'AVERTISSEMENTS = 0
JOBS PARTICIPANTS A CE TEST :
TYPE JOB ETAT AA MM JJ HH MM
<EMI ID=8.1>
Comme représenté dans l'organigramme de la Fig. 3, un test F est alors effectué sur le job. Si le nombre d'erreurs NBR D'ERREURS et le nombre d'avertissements.NBR D'AVERTISSEMENTS sont tous deux zéro 0 (ce qui est le cas pour JOB1), le job est chargé en mémoire par une opération G après la réponse non N (pas d'erreurs ni avertissements) au test F. Au contraire, si un avertissement ou une erreur est mentionné à la fin du Test-Rapide le job retourne au rectangle B après la sortie oui Y du test F.
Le programme suivant appelé par l'opérateur dans l'exemple est supposé être un programme de mesure de trafic de voie représenté dans le TABLEAU 6. Ce programme est appelé le 11 Juillet 1984 à 8h00 (S2 à la Fig. 2) et est donc le deuxième job JOB2 de l'exemple. Son but est de mesurer le trafic sur les voies ayant les numéros 3, 10 et 16 chaque jour entre 12h00 (12 : 00) et
24h00 (24 : 00) en commençant le 18 Juillet 1984 (1984 & 7 & 18) et de rapporter les résultats sur l'équipement de télétype TTY2. Ces périodes de mesure sont représentées par les rectangles J2 dans la Fig. 2.
<EMI ID=9.1>
Le JOB2 suit la même séquence d'opérations que le JOB1 sauf que pour le test C, qui demande.s'il existe déjà autres jobs, la réponse est maintenant oui Y. Une opération suivante H, montrée dans l'organigramme de la Fig. 3, consiste à charger ces autres jobs afin qu'ils participent, ensemble avec le JOB2, au Test-Rapide.
Le rapport généré par le Test-Rapide pour le JOB2 est donné dans le TABLEAU 7 et est similaire à celui généré pour le JOB1 (TABLEAU 5). Puisque pour le JOB2 aucune date de fin n'est donnée comme paramètre d'entrée, ce job sera exécuté indéfiniment et il sera donc impossible de le simuler entièrement si aucune précaution n'est prise. C'est pour cette raison que le temps d'exécution du Test-Rapide est limité à un maximum de 5 minutes, comme déjà mentionné ci-dessus. C'est pourquoi la RAISON DE FIN du JOB2 est que le TEMPS DE TEST est EPUISE (HEURE-DEBUT : MM=20, HEURE-FIN : MM=25). Le rapport de test mentionne aussi zéro erreurs (NBR D'ERREURS = 0) et un avertissement (NBR D'AVERTISSEMENTS
1) qui va être discuté plus loin. Les JOBS PARTICIPANTS A CE TEST sont JOB1 (comme décrit ci-dessus) et JOB2 qui est du TYPE mesure de trafic de VOIE. Pendant les 5 minutes que dure le Test-Rapide, il a été possible de simuler le calendrier du JOB2 jusqu'au 23 Juillet 1984 à OOhOO (1984 & 7 & 23, 00 : 00). Pour cette raison l'ETAT du JOB2 à la fin du test est indiqué comme PLANNIFIE au lieu de TERMINE comme pour le JOB1.
Plus de détails sur l'avertissement sont donnés immédiatement après le rapport du test. L'erreur qui était la cause de cet avertissement a été détectée pour
le JOB2 à 12h00 le 18 Juillet 1984 (1984 & 7 & 28 ,
12 : 00) - calendrier simulé - lorsque le COMPTEUR de PROGRAMME était à l'adresse 266. L'avertissement était
du TYPE VOIE et le NUMERO était 16, c'est-à-dire la voie ayant le numéro 16. Comme clairement indiqué à la dernière ligne du rapport d'avertissement, la RAISON DE L'AVERTISSEMENT est que la voie 16 N'EXISTE PAS. En effet, selon les limitations du central données ci-dessus, les seuls numéros de voies valables sont de 1 à 15.
<EMI ID=10.1>
Comme il y a un avertissement pour JOB2 la réponse au test F de l'organigramme est oui Y et pour cette raison JOB2 doit recirculer dans l'organigramme en commençant par le rectangle B. Cependant, avant ces opérations, l'identification de la voie IDENT-VOIE dans le tableau 6 sera corrigée en omettant la valeur 16. Le rapport du Test-Rapide obtenu après ce nouveau test est similaire à celui de TABLEAU 7, sauf pour le nombre d'erreurs et le nombre d'avertissements sont maintenant tous deux zéros et qu'aucun rapport d'avertissement ne sera donc généré à la fin de ce rapport.
Un troisième job JOB3 est supposé être activé le
13 Juillet 1984 à 12h00 (S3 sur Fig. 2) et consiste à mesurer le trafic sur les VOIES 8, 10 et 14 chaque jour
<EMI ID=11.1>
17 Juillet 1984 (1984 & 7 & 17). Le rapport devra être imprimé sur l'équipement de télétype TTY1. Ces paramètres d'entrée sont montrés dans le TABLEAU 8 et le job est schématiquement représenté par les rectangles J3 dans la Fig. 2.
<EMI ID=12.1>
Le rapport du Test-Rapide du JOB3 est montré dans le TABLEAU 9. Il a été imprimé le 13 Juillet 1984 à
12h35 et est similaire à celui généré,pour le JOB2. Comme il n'y avait pas de date de fin donnée comme paramètre d'entrée, la RAISON DE la FIN de ce test du JOB3 est due à l'expiration des 5 minutes d'exécution maximales attribuées à ce test (HEURE-DEBUT . MM=26, HEURE-FIN : MM=31). Pour cette raison le JOB3 a seulement pu être simulé jusqu'au 22 Juillet 1984 à 18h00
(1984 & 7 & 22 , 18 : 00) et pendant cette simulation aucun avertissement et aucune erreur n'ont été détectés.
Il est à noter que puisque le Test-Rapide est effectué pour le JOB3 et que la simulation de ce dernier se termine le 22 Juillet à 18h00, la simulation des autres JOBS PARTICIPANTS A CE TEST est également terminée à la même date et à la même heure. Ceci est particulièrement vrai pour le JOB2 dont la simulation est donc interrompue.
<EMI ID=13.1>
Le dernier job de l'exemple est le JOB4 activé le
14 Juillet 1984 à 16h00 (S4 à la Fig. 2). Le but de ce job est d'observer la ligne d'abonné ayant le numéro 2829 du 17 Juillet 1984 (1984 & 7 & 17) à OhOO (00 : 00) jusqu'au 20 Juillet 1984 (1984 & 7 & 20) à 18h00 (18 :
00) comme indiqué par les paramètres d'entrée montrés dans le TABLEAU 10. Le dispositif de sortie est l'équipement de télétype TTY2. Ce JOB4 est représenté par le rectangle J4 dans la Fig. 2. Il n'a qu'une période de travail PERIODE1.
<EMI ID=14.1>
Le rapport de Test-Rapide correspondant est donné dans le TABLEAU 11. Le test du JOB4 a pris 2 minutes
(HEURE-DEBUT . MM=38, HEURE-FIN : MM=40) et le rapport a été imprimé le 14 Juillet 1984 à 17h43 (1984 & 7 & 14 ,
17 : 43). La simulation du JOB4 était terminée à la fin du test, c'est-à-dire le 20 Juillet 1984 à 18h00 - temps simulé. Le nombre d'erreurs est zéro et il y a 3 avertissements qui seront considérés plus loin. Les quatre jobs JOB1-4 ont participés à ce test et la simulation des jobs JOB1-3 était terminée ou interrompue au moment où la simulation du JOB4 (LE JOB REQUERANT LE TEST) était TERMINEe, c'est-à-dire le 20 Juillet à 18h00. En effet, la simulation des jobs JOB1-3 n'aurait pas pu être terminée à cette date. Leur ETAT à la fin du test est donc indiqué comme PLANNIFIE au lieu de TERMINE.
<EMI ID=15.1>
<EMI ID=16.1>
Les trois avertissements sont maintenant décrits plus en détail en faisant référence au contenu des RAPPORT D'AVERTISSEMENTS correspondants montrés dans le TABLEAU 11.
Le premier RAPPORT D'AVERTISSEMENT pour le JOB4 indique que le 17 Juillet 1984 à 11h00 et lorsque le COMPTEUR-PROGRAMME était à l'adresse 356, un CONFLIT DE RESSOURCES (RAISON DE L'AVERTISSEMENT) se produit avec le JOB1, c'est-à-dire l'observation de la LIGNE D'ABONNE ayant le numéro 4819. En effet, selon les limitations du central données ci-dessus, une seule ligne d'abonné peut être observée à un même instant. Il est à noter que 1984 & 7 & 17 , 11 : 00 sont la date et l'heure de début de la première période DEBUT-PERIODE1, J1A du JOB1.
Le deuxième RAPPORT D'AVERTISSEMENT pour le JOB4 indique que le 18 Juillet 1984 à 12h00 le NOMBRE MAXimum DE JOBS est ATTEINT. Ceci devient également apparent à la Fig. 2 qui montre clairement qu'à cet instant les JOB1
(J1A), JOB3 (J3) et JOB4 (J4) sont tous en exécution de telle sorte que le nombre maximum (3) de jobs au travail fixé par les limitations du central données ci-dessus est atteint. A ce moment l'exécution du JOB2 devrait commencer et est donc la raison de cet avertissement.
Le troisième RAPPORT D'AVERTISSEMENT pour le JOB4 est similaire au deuxième et indique que le 20 Juillet
1984 à 14h00 le NOMBRE MAXimum DE JOBS est à nouveau ATTEINT. En effet, les JOB2 (J2), JOB3 (J3) et JOB4 (J4) sont tous en exécution alors que la seconde période de travail PERIODE2 du JOB1 (J1B) devrait commencer
(DEBUT-PERIODE2).
Après que les tests des jobs décrits ci-dessus aient été exécutés et aient donnés des résultats acceptables, ces jobs sont exécutés suivant leurs calendriers réels respectifs. Chaque fois qu'un calendrier réel d'un job est terminé, ce job est éliminé et ne participe donc plus au Test-Rapide.
En résumé, la méthode de test de programme ou Test-Rapide décrite ci-dessus simule l'opération de jobs avant leur exécution réelle. Tout les jobs participent à un tel test afin de détecter non seulement des erreurs dans les jobs mais aussi des conflits possibles entre eux.
Bien que les principes de l'invention aient été décrits ci-dessus en se référant à des exemples particuliers, il est bien entendu que cette description est faite seulement à titre d'exemple et ne constitue aucunement une limitation de la portée de l'invention.
REVENDICATIONS
1. Méthode pour tester au-moins un programme qui est normalement exécuté suivant un calendrier, caractérisée en ce qu'elle consiste à exécuter ledit programme suivant un second calendrier fonction dudit calendrier mentionné premièrement.
METHOD FOR TESTING A PROGRAM
The present invention relates to a method for testing at least one program which is normally executed on a schedule.
When the program execution time is long, the time required to test the program has a corresponding length since program errors can appear even near the end of the test.
An object of the present invention is to provide a method of the type mentioned above, but which allows a relatively rapid test of the program.
According to the invention, this object is achieved by the fact that the method consists in executing said program according to a second calendar function of said calendar mentioned first.
Another characteristic of the present method is that said second calendar is proportional to and executed faster than said first calendar.
Because the program execution time can therefore be considerably reduced, even program errors occurring near the end of this test appear relatively early.
Yet another characteristic of the present method is that it consists in executing said program according to said second calendar before executing it according to said first calendar.
In this way, errors occurring during the execution of the test can be corrected before the program is executed normally.
Yet another characteristic property of the present method is that it consists in testing a plurality of said programs by executing them according to corresponding second schedules.
In this way, conflicts between programs running simultaneously are detected very early.
The objects and characteristics of the invention described above as well as others and the manner of obtaining them will become clearer and the invention itself will be better understood, with reference to the following description of an exemplary embodiment of the invention taken in conjunction with the accompanying drawings:
Fig. 1 is a schematic view of a telecommunications system using a test method according to the invention; Fig. 2 is a calendar showing programs to be tested by this method; Fig. 3 is a flow diagram illustrating various steps of the test method.
The program test method known as Quick Test described below is used in a telecommunication system to test various programs which are contained in a memory, for example a disk drive 1 shown in FIG. 1, coupled to a telecommunications center 2 provided with a plurality of subscriber lines such as 4 and a plurality of junctions such as 5 forming a number of channels. These programs can be called up at any time by an operator via his desk or any other terminal 3, for example teletype equipment, coupled to the central office 2. When such a program is called up by an operator in order to carry out a measurement or a particular observation, the operator enters parameters into the program via instructions or commands.
These parameters indicate what should be measured or observed and when it should be done. When the program is provided with these parameters and activated by the operator, it becomes a "job".
Three types of programs are considered: a subscriber line observation program, a channel traffic measurement program and a program to deactivate selected jobs.
In more detail, the commands and input parameters for the subscriber line observation program are given in TABLE 1 and are as follows: <EMI ID = 1.1> of the subscriber line for which the observation must be made is entered after the IDENT-SUBSCRIBER label;
- the date and time of the start of an observation period expressed in "year & month & day" and "hour: minute" respectively are entered after the START-PERIOD label, where n is the period number ;
- the date and time of the end of an observation period expressed in "year & month & day" and "hour: minute" respectively are entered after the label FIN-PERIODEn;
- the identity of the "output-device" on which the observation report must be generated is entered after the DEVICE-OUTPUT label.
Note that if more than one observation is required, for example PERIODE1, PERIODE2, the start and end parameters are given for each of these required periods.
<EMI ID = 2.1>
<EMI ID = 3.1>
The commands for the channel traffic measurement program are given in TABLE 2 and are as follows: <EMI ID = 4.1> numbers of the channels for which the measurements must be made are entered after the IDENT-TRACK label;
- the start date of the measurement expressed in "year & month & day" is entered after the START-DATE label;
- the start time of the measurement expressed in "hour:
minute "is entered after the TIME-START label;
- the end time of the measurement expressed in "hour:
minute "is entered after the TIME-END label;
- the identity of the "output-device" on which the measurement results are to be printed is entered after the DEVICE-OUTPUT label.
<EMI ID = 5.1>
It should be noted that the track traffic measurement program differs from the subscriber line observation program by the fact that the former is automatically repeated every day during the same period defined by the HOUR-START and the HOUR-END and begins on the DATE-START, while the second is executed only during the PERIOD (s) defined by the corresponding input parameters. However, a lane traffic measurement program may contain a DATE-STOP command indicating the date and time of the end of this job. Another way to stop the lane traffic measurement program is to use the JOB-DEACTIVATION program to deactivate selected measurements, which is described below.
The commands for the job deactivation program are shown in TABLE 3 and are as follows:
- the sequence number or "job-number" of the job which must be deactivated is entered after the IDENT-JOB label;
- the deactivation date expressed in "year & month & day" is entered after the DATE-STOP label.
The job number is a number that is automatically assigned to any job activated by an operator. It should be noted that the DATE-STOP is optional and that when no DATE-STOP is given deactivation is immediately effective.
<EMI ID = 6.1>
A test of feasibility of execution or of feasibility called Quick-Test is carried out for each new job and consists in immediately testing the limitations of the exchange, the possible conflicts with other jobs and the available memory which will have to be shared with others jobs.
This test will be better understood by the following description of an example given in TABLES 4 to 11 and illustrated by Figs. 2 and 3. For this example the limitations of the exchange are assumed to be as follows:
- only the channels numbered from 1 to 15 exist;
- several subscriber line observation jobs can be executed simultaneously, but no more than one subscriber line can be observed at the same time;
- the maximum number of jobs running is 3;
- the execution time of the Quick Test is limited to a maximum of 5 minutes.
In the example, on July 10, 1984 at 12:30 pm an operator calls a subscriber line observation program in order to observe the subscriber line having the number 4819 during a first period PERIODE1 extending from July 17, 1984 to 11:00 a.m. (1984 & 7 & 17,
11:00) to July 18, 1984 at 2:00 p.m. (1984 & 7 & 18,
2:00 p.m.) and during a second PERIODE2 period from July 20, 1984 to 2:00 p.m. (1984 & 7 & 20,
2:00 p.m.) to July 21, 1984 at 6:00 a.m. (1984 & 7 & 21,
06:00). These values are therefore entered by the operator and the sequence number 1 is assigned to the corresponding job, that is to say JOB1. The output device for JOB1 is the teletype equipment number 2 TTY2.
<EMI ID = 7.1>
The JOB1 calendar is shown schematically in FIG. 2 where the values on the time axis t are the calendar days of the month of July
1984. In more detail, the activation date of JOB1 is represented by SI and the work periods PERIODE1 and PERIODE2 are represented by J1A and J1B respectively.
Referring to the flowchart shown in Fig. 3, the call to a program is indicated there by a rectangle A and a rectangle B represents the entry of the parameters in this program. When this operation is finished a C test is done to find out if other jobs are already running. As JOB1 is the first job the answer to test C is no, that is to say N. the Quick Test is then executed on JOB1 as represented by the rectangle D in the flowchart. This test consists in checking the possibility of execution of the job by simulating its real execution, that is to say by executing this job with a clock which is much faster than the real time clock. The simulated calendar for this job is therefore scanned in a few minutes instead of, for example, several hours or even several days for the real calendar.
In other words, the job is executed according to a schedule depending on the actual schedule of this job. During this test, all the operations for entering and leaving the real job are simulated so that no time is wasted waiting for responses or possible inputs from the exchange or its peripherals. The test is terminated when the fast clock reaches the last end date of the job being tested or when the maximum execution time allocated to the test is exceeded.
A report such as that shown in TABLE 5 is generated at the end of the Quick Test. This report, represented by rectangle E in the flow diagram of FIG. 3, contains brief information about the job tested and the test results. In more detail, the first line of this report gives the job sequence number JOB1 and is followed by the date and time of the test expressed in year 1984, month 7, day 10, hour 12 and minute 32. The difference between the TEST END TIME and TEST START TIME indicates that this test only lasts for about one minute MM = 31 - MM = 30. There are no errors (NBR OF ERRORS = 0), nor warnings (NBR OF WARNINGS = 0) so that the REASON FOR THE END of this job is that the simulated schedule of the JOB REQUIRING THE TEST has been completed or IS COMPLETED.
The fact that there are no errors or warnings gives a first indication of the possibility of executing the job. This means that the subscriber line with number 4819 exists, that the TTY2 output device is available and that there is enough memory to execute this job. The last line of the Quick Test report provided, for all JOBS PARTICIPATING IN THIS TEST, i.e. only JOB1 in this case, the following information:
- the TYPE of job: ABNN means a subscriber line observation;
- the identification of the JOB or sequence number of job 1;
- the STATE of this job at the end of the test: the job was COMPLETED on 1984 & 7 & 21 at 6:00 am which is the last date and time of the end of this job.
TABLE 5
QUICK TEST REPORT:
JOB1; 1984 & 7 & 10, 12:32
TIME-START OF TEST = 1984 & 7 & 10, HH = 12: MM = 30 TIME-END OF TEST 1984 & 7 & 10, HH = 12: MM = 31 REASON FOR END = JOB REQUESTING TEST IS OVER
NBR OF ERRORS 0
NBR OF WARNINGS = 0
JOBS PARTICIPATING IN THIS TEST:
TYPE JOB STATE AA MM DD HH MM
<EMI ID = 8.1>
As shown in the flow diagram of FIG. 3, an F test is then performed on the job. If the number of errors NBR OF ERRORS and the number of warnings.NBR OF WARNINGS are both zero 0 (which is the case for JOB1), the job is loaded into memory by an operation G after the response no N (no errors or warnings) on test F. On the contrary, if a warning or an error is mentioned at the end of the Quick Test the job returns to rectangle B after the yes Y exit from test F.
The following program called by the operator in the example is assumed to be a channel traffic measurement program shown in TABLE 6. This program is called on July 11, 1984 at 8:00 am (S2 in Fig. 2) and is therefore the second JOB2 job in the example. Its purpose is to measure the traffic on the tracks having the numbers 3, 10 and 16 every day between 12:00 p.m. (12:00 p.m.) and
24h00 (24: 00) starting on July 18, 1984 (1984 & 7 & 18) and reporting the results on the TTY2 teletype equipment. These measurement periods are represented by the rectangles J2 in FIG. 2.
<EMI ID = 9.1>
JOB2 follows the same sequence of operations as JOB1 except that for test C, which asks. If there are already other jobs, the answer is now yes Y. A following operation H, shown in the flowchart in Fig . 3, consists of loading these other jobs so that they participate, together with JOB2, in the Quick Test.
The report generated by the Quick Test for JOB2 is given in TABLE 7 and is similar to that generated for JOB1 (TABLE 5). Since for JOB2 no end date is given as an input parameter, this job will be executed indefinitely and it will therefore be impossible to simulate it entirely if no precautions are taken. It is for this reason that the execution time of the Quick Test is limited to a maximum of 5 minutes, as already mentioned above. This is why the END REASON of JOB2 is that the TEST TIME is EXHAUSTED (HOUR-START: MM = 20, HOUR-END: MM = 25). The test report also mentions zero errors (NBR OF ERRORS = 0) and a warning (NBR OF WARNINGS
1) which will be discussed later. The JOBS PARTICIPATING IN THIS TEST are JOB1 (as described above) and JOB2 which is of the TYPE of TRACK traffic measurement. During the 5 minutes of the Quick Test, it was possible to simulate the JOB2 calendar until July 23, 1984 at OOhOO (1984 & 7 & 23, 00: 00). For this reason the STATE of JOB2 at the end of the test is indicated as PLANNED instead of DONE as for JOB1.
More details about the warning are given immediately after the test report. The error that was the cause of this warning was detected for
JOB2 at 12 noon on July 18, 1984 (1984 & 7 & 28,
12: 00) - simulated calendar - when the PROGRAM COUNTER was at address 266. The warning was
of the TYPE TRACK and the NUMBER was 16, that is to say the track having the number 16. As clearly indicated on the last line of the warning report, the REASON OF THE WARNING is that the track 16 DOES NOT EXIST NOT. Indeed, according to the limitations of the exchange given above, the only valid channel numbers are from 1 to 15.
<EMI ID = 10.1>
As there is a warning for JOB2 the answer to the F test of the flowchart is yes Y and for this reason JOB2 must recirculate in the flowchart starting with the rectangle B. However, before these operations, the identification of the channel IDENT-CHANNEL in table 6 will be corrected by omitting the value 16. The report of the Rapid Test obtained after this new test is similar to that of TABLE 7, except for the number of errors and the number of warnings are now all two zeros and therefore no warning report will be generated at the end of this report.
A third JOB3 job is supposed to be activated on
July 13, 1984 at 12:00 p.m. (S3 in Fig. 2) and consists of measuring the traffic on TRACKS 8, 10 and 14 every day
<EMI ID = 11.1>
July 17, 1984 (1984 & 7 & 17). The report should be printed on the TTY1 teletype equipment. These input parameters are shown in TABLE 8 and the job is schematically represented by the rectangles J3 in FIG. 2.
<EMI ID = 12.1>
The JOB3 Quick Test report is shown in TABLE 9. It was printed on July 13, 1984 at
12:35 and is similar to the one generated, for JOB2. As there was no end date given as an input parameter, the REASON FOR THE END of this JOB3 test is due to the expiration of the 5 minutes of maximum execution allocated to this test (HOUR-START. MM = 26, END-TIME: MM = 31). For this reason JOB3 could only be simulated until July 22, 1984 at 6:00 p.m.
(1984 & 7 & 22, 18: 00) and during this simulation no warning and no error were detected.
It should be noted that since the Quick Test is performed for JOB3 and that the simulation of the latter ends on July 22 at 6:00 p.m., the simulation of the other JOBS PARTICIPATING IN THIS TEST is also completed on the same date and at the same hour. This is particularly true for JOB2, the simulation of which is therefore interrupted.
<EMI ID = 13.1>
The last job in the example is JOB4 activated on
July 14, 1984 at 4:00 p.m. (S4 in Fig. 2). The purpose of this job is to observe the subscriber line with the number 2829 from July 17, 1984 (1984 & 7 & 17) at OhOO (00: 00) until July 20, 1984 (1984 & 7 & 20) at 6:00 p.m. (6 p.m.
00) as indicated by the input parameters shown in TABLE 10. The output device is the TTY2 teletype equipment. This JOB4 is represented by the rectangle J4 in FIG. 2. He has only one PERIODE1 work period.
<EMI ID = 14.1>
The corresponding Quick Test report is given in TABLE 11. The JOB4 test took 2 minutes
(HOUR-BEGINNING MM = 38, HOUR-END: MM = 40) and the report was printed on July 14, 1984 at 5:43 p.m. (1984 & 7 & 14,
17:43). The simulation of JOB4 was finished at the end of the test, that is to say on July 20, 1984 at 6:00 p.m. - simulated time. The number of errors is zero and there are 3 warnings which will be considered later. The four JOB1-4 jobs participated in this test and the simulation of JOB1-3 jobs was finished or interrupted when the simulation of JOB4 (THE JOB REQUIRING THE TEST) was COMPLETE, that is to say on July 20 at 6 p.m. Indeed, the simulation of JOB1-3 jobs could not have been completed on this date. Their STATUS at the end of the test is therefore indicated as PLANNED instead of DONE.
<EMI ID = 15.1>
<EMI ID = 16.1>
The three warnings are now described in more detail with reference to the content of the corresponding WARNING REPORT shown in TABLE 11.
The first WARNING REPORT for JOB4 indicates that on July 17, 1984 at 11:00 am and when the PROGRAM METER was at address 356, a CONFLICT OF RESOURCES (REASON OF THE WARNING) occurs with JOB1, it is that is, the observation of the SUBSCRIBER LINE having the number 4819. Indeed, according to the limitations of the exchange given above, only one subscriber line can be observed at the same time. It should be noted that 1984 & 7 & 17, 11:00 am are the date and the hour of beginning of the first period BEGIN-PERIOD1, J1A of JOB1.
The second WARNING REPORT for JOB4 indicates that on July 18, 1984 at 12:00 noon the MAXIMUM NUMBER OF JOBS is REACHED. This also becomes apparent in FIG. 2 which clearly shows that at this time the JOB1
(J1A), JOB3 (J3) and JOB4 (J4) are all running so that the maximum number (3) of jobs at work set by the limitations of the central office given above is reached. At this point the execution of JOB2 should start and is therefore the reason for this warning.
The third WARNING REPORT for JOB4 is similar to the second and indicates that on July 20
1984 at 2 p.m. the MAXIMUM NUMBER OF JOBS is REACHED again. Indeed, JOB2 (J2), JOB3 (J3) and JOB4 (J4) are all in execution while the second PERIODE2 work period of JOB1 (J1B) should start
(START-PERIODE2).
After the tests of the jobs described above have been executed and have given acceptable results, these jobs are executed according to their respective actual schedules. Each time a real schedule for a job is completed, this job is eliminated and therefore no longer participates in the Quick Test.
In summary, the program test or Quick Test method described above simulates the operation of jobs before their actual execution. All the jobs participate in such a test in order to detect not only errors in the jobs but also possible conflicts between them.
Although the principles of the invention have been described above with reference to specific examples, it is understood that this description is made only by way of example and does not constitute in any way a limitation of the scope of the invention .
CLAIMS
1. Method for testing at least one program which is normally executed according to a calendar, characterized in that it consists in executing said program according to a second calendar depending on said calendar mentioned above.