KR920002484B1 - Testing system of switching center - Google Patents

Abstract

The system includes a test implementing means (30) for transmitting and receiving messages with a multiplexing technique. A test procedure translating means (20) converts standard testing procedures to an intermediate machine language, and carries out the testing procedure. A high speed loading means (40) loads a target program into an electronic switching system (3) at a high speed, and a menu panel servo (10) furnishes user interfaces to the means (20, 30, 40). The preparatory time for the test is shortened, and the man hour required for the test is reduced.

Description

Electronic exchange test environment system

1 is a block diagram of the present invention.

2 is a flowchart showing the flow of the menu panel server.

3 is a flow chart for the step of creating a user test procedure.

4 is a flowchart for a test performer.

Figure 5a is a rack configuration of the high speed loader interface.

Figure 5b is a block diagram showing a high speed loading environment.

6 is a flow chart for a high speed loader.

7 is a flowchart for a fast loader interface.

* Explanation of symbols for main parts of the drawings

2: switchboard environment simulator (XES) 3: electronic switchboard

10: menu panel server 20: user test procedure generator

30: test performer 40: high speed loader

50: Fast Loader Interface 70: Purpose Program

The present invention creates a standardized test procedures in accordance with the external requirements and functional definitions of a system supporting the functional exchange of the electronic exchange, in particular the electronic exchange, and after the rapid loading of the target programs to be tested into the target system, A test environment system for performing tests using written test procedures.

The functional test of the electronic exchange is divided into two stages. The first is to prepare test procedures as a test preparation step and to load the functional blocks to be tested into the respective processors of the exchange. Secondly, in the test phase, the loaded timber programs are tested at the user interface level using tools such as Man-Machine Language (MML) and traffic simulators.

In Korea, the test procedures necessary to test the function of the exchange are often written without any form, and the target programs to be tested by the loader using the RS232C protocol are loaded and tested manually. Therefore, the accuracy of the test was highly dependent on the experience and knowledge of the person writing the test procedure. In addition, manual tests take a long time to understand the time and performance of test procedures, and errors are caused by the boredom or misunderstanding of the test. In addition, loaders using the RS232C protocol have bottlenecks in developing large software projects such as exchanges due to their speed limitations.

On the other hand, test support systems for performing functional tests have already made great progress in foreign countries. Such representative organizations include NEC in Japan, Hadachi, AT &T; GTE in the US, and LM Ericsson in Sweden. A common approach for functional testing in these institutions is to write test procedures to perform the tests and to provide test tools to perform them automatically. The concept of writing test procedures and running them automatically is a fairly advanced approach. However, these organizations enumerate test procedures that enumerate human-to-machine languages that are staged in the target system or use existing compilers. The method of writing simple enumerated test procedures takes a long time, since a very large test procedure must be written depending on the combination of the arguments of the license-to-machine languages. The method of writing test procedures using a compiler is difficult to learn due to the characteristics of the language and is inadequate to describe test procedures in test methods using licensed versus machine languages. In addition, in most cases, the test procedures are automatically carried out using only one communication line, and thus it is impossible to integrate the test process through multiple communication lines.

As mentioned above, the loading time of the target program and the time required for preparation and execution of the test are important factors for shortening the large-scale software development time.

An object of the present invention is to provide an integrated test environment system that can minimize test preparation and execution time in software development of an electronic exchange.

The integrated test environment in the present invention is a fast loading means for minimizing the time required for loading the target program, generating means for translating the standardized test procedure to generate a test procedure for testing the target system, the test procedure automatically Test means for performing, and interface means for matching them for ease of use.

In addition, to minimize test preparation time and to overcome manual testing, a test language is required to formulate a formal test procedure. In the present invention, the test language extends the syntax of XES (eXchange Environment Simulator) simulation control instructions, which is an exchange environment simulator for simulating CCITT versus machine language and calls, and introduces various syntaxes provided in a high-level programming language on the test environment system. The design was prioritized for development. The stack machine was designed to facilitate the translation of standard test procedures based on the test language into user test procedures. Most of the exchange functional tests are carried out on at least two RS232C communication lines. Therefore, the test run shall be able to control the messages sent / received over multiple communication lines. A synchronized input / output multiplexing method is introduced to poll corresponding receiving devices to process messages simultaneously received through multiple communication lines. In addition, to overcome the limitations of the conventional loading method using the RS232C protocol, a high-speed parallel bus, an IEEE-488 CPIB bus and a communication bus between processors, is adopted.

Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings.

1 is a schematic diagram of an actual environmental test system. The actual environmental functional test system is the test environment system (1), the XES (2), and the target system is the system consisting of the electronic exchanger (3). In the present invention, the components of the test environment system built in the host system in the actual environment functional test system (dotted line in FIG. 1) will be described, so that the well-known XES and electronic exchanger will not be mentioned. The test environment system is connected to other computers via a local area network (LAN, Ethernet) so that the test environment system can enter any computer system to provide an integrated test environment. The software blocks consist of a menu panel server 10, a user test procedure generator 20, a test executor 30, a fast loader 40 and a fast loader interface 50. Of these software blocks, test performer 30, fast loader 40, and fast loader interface 50 control the hardware. That is, the test performer 30 is connected to the electronic exchange 3 and the XES (2) through a plurality of RS232C communication lines 80 to control at least two communication lines at the time of testing, high-speed loader 40 Transmits loading data to the fast loader interface via the IEEE-488 GPIB bus 90, and the fast loader interface 50 transmits the loading data transmitted through the GPIB bus 90 to the inter-processor communication (IPC) bus 100. Transfers data to the exchange. On the other hand, it is not a software block but another important component of a test environment system, which crosses the standard test procedure library 60, which is a collection of standard test procedures written in the test language by the user according to the test specification, and the operating system and applications of the target system. There is an object program 70 which has been converted to object codes by a compiler or cross-assembler and these are stored on disk for testing or loading.

2 is a flowchart for explaining the operation of the menu panel 10 of FIG. The menu panel server is implemented in a menu-driven manner, in charge of interfacing each block of the test environment system with a user who enters the test environment system through a local area network or a terminal device. The menu panel server is in a waiting state for input 21 after being driven by the user. In this state, the following operation is performed according to the selected input mode 22. Standard test procedure performance (23) is to classify the standard test procedures written to test the software function of the electronic exchange into large and small items in a hierarchical library (Fig. 60), and user test procedures can be easily generated. It is responsible for copying and editing, and the interface 24 for driving the user test procedure generator (FIG. 20). The port reservation execution 25 is a function of outputting the current state of the port and the function of outputting the current state of the port for efficient sharing of the RS232C port (FIG. 80) connected to the electronic exchange 3 and the XES 2 under test. In charge of the reservation and cancellation functions. The test performer execution 25 defines the input parameters required to interface the various test execution modes related to the test execution with the test performer and then operates the test performer. The document processing execution 37 performs copying and editing functions to manage various documents related to the test environment. Network execution 28 is responsible for the file transfer function of the network and target programs with other development host systems over the local area network of FIG. The high speed loader execution 29 defines parameters necessary for performing the high speed loader, and is in charge of the interface with the high speed loader. Help execution 210 describes the contents and usage of each panel, but is responsible for the function to enable the user to use the menu panel server without a manual. After the above operations are performed by the selected input menu, the user transitions to the input standby state and performs another task repeatedly. Finally, the execution of the menu panel server is finished by the end menu 211.

Standard test procedures written in test languages may not be performed directly on the target system. To be performed in the test phase, they must be converted to a user test procedure, which is a specific type of command file that can be executed on the target system. The user test procedure generator (FIG. 20) performs the translation function of the standard test procedure and this process is illustrated by the steps in FIG. The series of input characters of the standard test procedure is separated into token units according to the pattern law defined in token analysis step 31. In this process, unnecessary characters (tabs, line feeds, blanks) are removed. The token here refers to an attribute in which the scanned pattern is implied. Representative tokens of test procedure description languages include reserved words, identifiers, constants (2,8, 10, hexadecimal numbers, keyed numbers, etc.), operators, literal strings, real parameters, punctuation symbols (parentheses, commas, semicolons, colons, etc.). And more specifically, the token type. These tokens can have any value (attribute) besides their type, and they are called token values. Thus, tokens are represented by <type, value> and any tokens retrieved at another level, such as identifiers, constants, literal strings, etc., are stored in the symbol table by the symbol table management step 34. Patterns other than the token types in the token analysis step are output to the user as a message in the error output step 35 if lexical error.

The stream of tokens, which is the normal output of the discussion analysis stage, is input to the next stage, the stack machine code generation stage 32. In the code generation step 32, which is a stack machine, a series of token streams are repeatedly called for a token analysis process until they are combined into logical execution units. Errors occurring in the combining process are syntax errors that violate the grammar of the test procedure description language and they are output to the user in the error analysis step 35. At the end of the analysis of logical units of execution, such as procedure definitions and calls, compound statements, loops, selections, substitutions, human-to-machine languages, homomorphic instructions, and expressions, they are the same as the stack machine codes shown in Table 1. In the symbol table management step, a combination of information about stored symbols is generated and stored in a memory area. Some symbols change their properties during the grammar analysis. For example, in the case of a substitution statement (identifier: = formula), the token type called identifier defined in the token analysis step has a value obtained by calculating the stack machine formula, so that the symbol generation is replaced with a cotton type called a variable in the code generation step. In the table management step 34, the symbol table is changed and stored. The translation technique applied in the stack machine code generation step adopts a syntax-oriented translation method that adds the semantic rule for generating stack machine codes to the grammar of the test procedure description language.

The stack machine codes stored in the memory area are input to the stack machine performing step 33. The stack machine code execution step 33 sets a virtual program counter, a data stack and a stack pointer, and a procedure frame as a execution environment in order to execute stack codes stored in a memory area. The program counter stores the address value of the stack machine codes to be performed next among the stack machine codes stored in the memory area. The data stack is used to retrieve, modify, and save data used in the code execution stage, which is a stack machine, and is a data structure in which the last stored data is searched first. Operation on the data stack is controlled by a stack pointer indicating the address of the last stored data. The procedure frame contains the information to be recovered after the procedure is executed, that is, the value of the program counter value to be executed after the procedure ends, the symbol table pointer for the procedure name at the time of the procedure call, the number of parameters, and the i-th parameter stored in the data stack. A data structure that stores information about addresses, etc. The stack machine code execution step 33 performs stack machine codes corresponding to logical execution units. The initial value (start address) of the program counter is automatically assigned after the generation step of the logic execution step in the stack machine generation step. The subsequent execution is performed using the program counter, the stack code operator (Table 1), the procedure frame, and the data stack. The results are output to a user test procedure file. Attributes for symbols may change in the course of execution and they are changed in symbol table management step 34. In addition, semantic errors for variables or constants, runtime errors occurring during execution are output to the user in the error output step 35. This step is repeated until the scanning of the standard test procedure file is complete.

TABLE 1

The test performer (FIG. 30) is a test tool that supports the performance of user test procedures created by or created by the user test procedure generator (FIG. 20). The test executor selects various input commands in the user test procedure and transmits them manually and automatically through the RS232C communication line (FIG. 80) to the corresponding processor of the XES or target system, and receives and stores the accompanying output messages. In charge. RS232C communication lines are often used as interfaces for exercise and maintenance functions, call traffic generation, and debugging purposes. The test typically consists of the procedures of setting up the test environment by the operational maintenance command of the target system, generating call traffic at XES, receiving the results, and finally releasing the test environment set by the operational maintenance command.

4 is a flowchart describing the operation of the test performer. Initially, the test performer is in an input wait state 41 waiting for data to be entered via the console or receiving device (FIG. 80). In this case, the console is defined as an input device of a user who uses a test environment system through a local area network, and a receiving device is defined as an input / output device connected to an RS232C communication line (FIG. 80) controlled by a test performer. When a character is input 42 from the console in the input waiting state, the type of the character is checked 201. If this character indicates the end of the test, the test is terminated (206). If the character is a character 202 having a specific meaning, the character transitions to the state 204 waiting for input again after performing a function as shown in Table 2. All characters (203) except these two types of characters are sent (203) to the destination system for XES or operational maintenance and debugging, which generates call traffic over the communication lines specified by the + port (Table 2) command. After the completion of the process, the process returns to the input wait state 205. The execution of the user test procedure results in a timeout signal generated by the wait command of Table 2, @ <time>, the ~ t <time> command that adjusts the command execution time, or an internal timer value (44), or the test procedure of Table 2. Commands such as [, @ r, @ s, @ c to control the execution of the command are initiated upon input to the console (42). After the timeout signal, the characters in the test procedure are selected (401), and if the current character represents the special commands shown in Table 2, then perform a function (402) on them. If it is a file mark indicating termination, the test execution ends (405).

All characters (403) except these two types of characters are sent to the destination system for XES or operational maintenance and debugging (403), which generates call traffic over the communication lines specified by the + port (Table 2) command. After the completion, the state transitions back to the input waiting state 404. If there are multiple inputs transmitted simultaneously from the XES or the target system after sending a message (203, 403) to the destination system on the receiving devices connected to the test runner in the input standby state (43) Polling to find out if a message has been sent on the communication line. The polling operation sequentially checks whether an input event has occurred in communication ports by multiplexing (301), and when an event occurs in the communication line under test, logs received from the communication line with the console. Print to file. After the polling operation is completed, the internal timer is operated as necessary and the state transitions back to the input waiting state 302. Multiplexing allows message input and output through up to 31 RS232C communication lines.

TABLE 2

Fast loading is performed by the test host of FIG. 1, the fast loader interface rack, and the GPIB bus, the interprocessor communication (IPC) buses and the fast loader, fast loader interface control software that controls them, between the target systems. Figure 5a shows the configuration of the high speed loader interface rack. The high speed loader interface rack was constructed by assembling the TMS9914 GPIBA (MVME300) board 55 to the electronic exchange main processor assemblies (51, 52, 53, 54). Where 52 is MPMA (M68020 central processing unit (CPU) + 64K local memory), 53 is MECA (main memory) and 54 is PCCA (inter-processor communication interface).

The matching between the test host, the fast loader interface rack, and the target system is illustrated in the fast loading environment diagram of FIG. 5b. FIG. 5b is a detailed block diagram showing parts 40, 50, and 70 of FIG. The flow of data between the GPIB controller device (GPIB-96IP) 56 of the test host system and the GPIBA controller device 57 of the high speed loader interface rack is the GPIB bus, which is responsible for interprocessor communication between the high speed loader interface rack and the target system. The I-node interfaces 58 and 59 are refrigerated and they transmit and receive data via an interprocessor communication bus, where the I-node interface 58 uses PCCA. Each driver is required to drive the hardware described above. The control of the high speed loader interface was made possible by programming (520,530,540,510) to support the fast loading function in the operating system of the target system.

The procedure for fast loading is described with the flowcharts of FIG. 6 and FIG. The fast loader interface (FIG. 5B 50) enters the GPIB receive state immediately after initial state setup, as in the FIG. 7 flowchart, and awaits messages 710, 720, 730 from the fast loader (FIG. 5B 40). The fast loader checks for GPIB bus availability (640), and if the bus is unavailable, the fast loader terminates (650). If the bus is available, the fast loader sends a processor status message to the fast loader interface and then waits to receive a processor status report (660). When the status request message of the processor is received by the fast loader interface (71), it sends a status request message (72) to the corresponding processor of the target system, receives the status report result, reports it to the fast loader (73), and then transitions back to the received state. . The fast loader, which was waiting to receive the processor status report, receives the processor status reception message (61) and analyzes the status of the processor from the message (62). If the processor state is abnormal, the loading is impossible and the execution of the fast loader is terminated (63). If the state of the processor is normal, the fast loader sends a loading start message to the fast loader interface (64). After the loading start message is transmitted, the fast loader transmits the target program stored in the disk to the fast loader interface as loading data (65). After the loading of the loading data is finished, the fast loader is in a state waiting for a loading completion message to be sent after the loading is finished in the fast loader interface.

When the fast loader interface system receives a loading start message (720), it secures enough buffers for storing the loading data (81) and then enters the receiving state again to wait for the loading data (82). Accepted in the interface reception state (730). The fast loader interface transmits header information of the loading file from the loading data to the target system (91). After sending the loading file header information, the fast loader interface transmits the loading data to the destination system (92). After transmission of every loading data, it is checked whether transmission is complete (93). If the transmission is not completed, the data is transmitted continuously ((2). After the transmission is completed, the loading completion message is transmitted to the target system (94), and then the loading system receives a loading information reception fee message from the target system (95). After the loading completion message is transmitted to the fast loader (96), the state transitions back to the GPIB reception state (97), and the fast loader, which is waiting for the reception of the loading completion message, receives the loading completion message (66) and then makes a request. Check whether all the loading files have finished loading (67) If the loading is completed, the fast loader terminates execution after outputting the loading completion message (68). The process is repeated.

The following items can be enumerated as effects expected by the present invention. First, the fast loader using the IEEE-488 GPIB bus reduces the time to prepare for the test by speeding up the loading speed frequently required by developers. Secondly, compared to manual testing, an automated test environment can perform many test procedures in the same time, maximizing the efficiency of available test times and reducing the manpower required for testing. Third, the test environment system enables the sending and receiving of messages through 31 communication lines, providing an integrated test execution environment and ensuring the consistency and high reliability of the test environment. Fourth, it is applicable to electronic exchanges (eg TDX-1 and TDX-10) that follow the input command syntax of the CCITT human-to-machine language and the RS232C protocol and can interoperate with call traffic generator XES.

Claims (3)

External requirements and functional definitions of the electronic exchange 3 connected to the electronic exchange 3 to be tested and to an exchange environment simulator (XES) 2 for simulating calls connected to the electronic exchange 3. A test environment system for creating test procedures standardized according to the present invention and loading the target programs to be tested in the target system and then performing tests using the created test procedures, wherein the switch environment simulator (XES) 2 and the electronic exchanger ( 3) using the input / output multiplexing technique used to transmit an input message through the multiple RS232C communication lines and to receive messages that can be transmitted simultaneously as a result in performing the test through the multiple RS232C communication lines. Test execution means 30, connected to the test execution step 30 to transfer the standard test procedure to intermediate codes on the internal stack machine. High speed loading means for converting and then performing this to generate a user test procedure so as to be connected to a test procedure translation means 20 and the test execution means 30 so that a target program can be loaded at high speed on the electronic exchange 3 ( 40), a high speed loader interface means 50 connected to the high speed loading means 40 and the electronic exchanger 3, and each of the means 20, 30 and 40 to provide a user interface by a menu driving method. Electronic panel test environment system, characterized in that consisting of a menu panel server (10). 2. A test environment system according to claim 1, wherein the connection between the fast loading means (40) and the fast loader interface means (50) is made of a GPIB bus. The test environment system according to claim 1, wherein the connection between the fast loader interface means (50) and the electronic exchange (3) is made by an interprocessor communication bus.

Images