CN101247292B - Test equipment and method based on universal test meter API - Google Patents
Test equipment and method based on universal test meter API Download PDFInfo
- Publication number
- CN101247292B CN101247292B CN2008101008147A CN200810100814A CN101247292B CN 101247292 B CN101247292 B CN 101247292B CN 2008101008147 A CN2008101008147 A CN 2008101008147A CN 200810100814 A CN200810100814 A CN 200810100814A CN 101247292 B CN101247292 B CN 101247292B
- Authority
- CN
- China
- Prior art keywords
- test
- api
- instrument
- library
- test instrument
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 525
- 238000000034 method Methods 0.000 title claims abstract description 28
- 238000013515 script Methods 0.000 claims abstract description 117
- 230000009471 action Effects 0.000 claims abstract description 23
- 238000010998 test method Methods 0.000 claims abstract description 6
- 238000012937 correction Methods 0.000 claims description 35
- 238000012812 general test Methods 0.000 abstract 4
- 230000002349 favourable effect Effects 0.000 abstract 1
- 230000008569 process Effects 0.000 description 15
- 238000004891 communication Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 238000012827 research and development Methods 0.000 description 5
- 238000004088 simulation Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000007619 statistical method Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a test equipment based on the general test meter application programming joint. The equipment comprises a test information input module, a test equipment initializing module, a test script explanation executing module, a test script analysis and amendment module, and a test meter base dynamic load module. Wherein, the test script analysis and amendment module is used for tracing the test action controlling test meter in the test script by transferring the general test meter application program joint (API) layer, according to the level structure of the joint in the general test meter API layer. The test meter base dynamic load module is used for obtaining judgment result from the test script analysis and amendment module, with corresponding load operation of test meter base. The invention further discloses a test method based on the general test meter application programming joint. By adopting the test equipment and method of the invention, the test instrument is enabled to satisfy the requirement in using efficiency for favorable and rapid operation test.
Description
Technical Field
The invention relates to a test technology, in particular to a test device and a test method based on a universal test instrument Application Programming Interface (API).
Background
With the rapid development of the data communication industry, various new data communication technologies and emerging data communication devices are in the endlessly, and accordingly, testing technologies for testing data communication devices and various special and general testing tools such as testing instruments are also developed and applied in large quantities. However, with the increasing level of testing and the deepening of testing level, the demands of various aspects of the test meter are increasing to meet the needs of testing. The new requirements are: the test instrument can meet the basic requirements on test functions and also can meet the requirements on use efficiency. Therefore, the test can be operated well and quickly, the test time is saved for manufacturers of data communication equipment, and the research and development cost is reduced.
However, in the testing process of the actual data communication device, i.e. the device under test, at present, there are often more than one types of test instruments used by the test engineer, and there are many functions of the device under test to be tested, so when only one type of test instrument is used in the whole testing process, and the test instrument only tests a single function of the device under test under the control of the test device, the problem of adopting the prior art is not too great; when a plurality of functions to multiple tester and equipment under test participate in the test, adopt prior art will appear more the problem that is difficult to solve, its reason lies in: according to the differences of the types of the test instruments and the differences of the test on the test instruments based on the functions of the tested equipment, when a test engineer writes a test script on the test equipment, a corresponding interface needs to be developed and set again each time according to the specific situation of the current test instrument, so that the current test instrument can test the tested equipment through the corresponding interface under the control of the test equipment. Therefore, the frequent setting of the interface between the test instrument and the device to be tested inevitably leads to low test efficiency, that is, the new requirements cannot be met.
The problems with the prior art are specifically described below.
On the one hand, due to differences of the test instruments, a test engineer puts too much effort in the aspects of familiarizing with functions and settings of the test instruments and finding or setting a suitable interface based on the functions and settings of the test instruments, so that the test engineer cannot concentrate on the implementation of the test scheme, and the implementation of the test scheme is the main purpose of automated testing. On the other hand, since the test meter defines APIs in different ways, both process-oriented and object-oriented, the interface provided to the user is different. In such an environment, a test script written by a test engineer based on one test instrument cannot be run under other test instruments, and the test script is not highly versatile.
Disclosure of Invention
In view of the above, the main objective of the present invention is to provide a testing device based on a universal test instrument API, and with the testing device, the testing instrument can satisfy not only the basic requirements on the testing function, but also the requirements on the use efficiency. Therefore, the test can be operated well and quickly, the test time is saved for manufacturers of data communication equipment, and the research and development cost is reduced.
The invention also aims to provide a test method based on the API of the universal test instrument, and by adopting the method, the test instrument can meet the basic requirements on test functions and the requirements on use efficiency. Therefore, the test can be operated well and quickly, the test time is saved for manufacturers of data communication equipment, and the research and development cost is reduced.
In order to achieve the purpose, the technical scheme of the invention is realized as follows:
a test device based on universal test instrument application programming interface comprises a test information input module, a test device initialization module, a test script interpretation execution module, a test script analysis and correction module and a test instrument library dynamic loading module; wherein,
the test script analysis and correction module is used for reading all the test scripts, calling the API layer of the universal test instrument and tracing the test action of the control test instrument in the test script according to the hierarchical structure of the interface in the API layer of the universal test instrument; wherein the universal test meter API layer is positioned above the bottom API layer of the existing test meter;
and the test instrument library dynamic loading module is used for acquiring a judgment result from the test script analysis and correction module after the test script analysis and correction module judges according to the upper tracing result, and carrying out corresponding test instrument library loading operation.
The test instrument library dynamic loading module is further used for obtaining a judgment result of the current single test instrument environment and loading the universal test instrument API library and the bottom API library of the test instrument to the global name space.
The test instrument library dynamic loading module is further used for obtaining the judgment result of more than one test instrument environment at present and loading the universal test instrument API library and the bottom API library of the test instrument to the corresponding name space.
A testing method based on a universal test instrument application programming interface comprises the following steps:
A. constructing a hierarchical architecture of an API and a hierarchical structure of an interface in an API layer of a universal test instrument; after the test script analysis and correction module reads all the test scripts, the test action of the control test instrument in the test script is traced up by calling the API layer of the universal test instrument and according to the hierarchical structure of the interface in the API layer of the universal test instrument; wherein the universal test meter API layer is positioned above the bottom API layer of the existing test meter;
B. and after the test script analysis and correction module judges according to the upper tracing result, obtaining a judgment result from the test script analysis and correction module, and carrying out corresponding test instrument library loading operation.
In step a, the manner of constructing the hierarchical architecture of the API specifically includes: and adding a universal test instrument API layer on the bottom API of the test instrument.
Wherein, still include after step B:
C. after the test script interpretation and execution module reads the relevant control information of the test script operation in the test script operation control file, the loaded test script is interpreted into an executable code by calling an interpreter, and then the executable code is executed on the test instrument.
In the step B, the loading operation of the corresponding test instrument library specifically includes: and when the test instrument library dynamic loading module acquires the judgment result of the single test instrument environment, loading the universal test instrument API library and the bottom API library of the test instrument into the global name space.
In the step B, the loading operation of the corresponding test instrument library specifically includes: and when the test instrument library dynamic loading module acquires the judgment result of more than one test instrument environment, loading the universal test instrument API library and the bottom API library of the test instrument to the corresponding name space.
Aiming at the API hierarchical architecture, the invention is different from the prior art, a universal test instrument API layer is added on the bottom API of the existing test instrument, and the test instrument API is uniformly developed and set on the universal test instrument API layer. The API layer of the universal test instrument is used for encapsulating the API of the bottom layer and providing a uniform interface for the operation of the test instrument to the API client of the upper layer for use, so as to complete the test of the test instrument on the device under test under the control of the test equipment of the present invention. Then, after adding the API layer of the universal test instrument, the test engineer writes a test script on the test equipment of the present invention based on the uniform interface provided by the API layer of the universal test instrument, so that the written test script runs under any test instrument without any change, thereby not only improving the universality of the test script, but also avoiding repeatedly writing the test script; but also shields the difference of the test instruments. Therefore, the testing efficiency is improved, and the research and development cost is reduced.
The test device is different from the existing test device, and a test script analysis and correction module and a test instrument library dynamic loading module are added. The test script analysis and correction module is used for tracing the test action of the control test instrument in the test script by calling the API layer of the universal test instrument and according to the hierarchical structure of the interface in the API layer of the universal test instrument. And then, the test script analysis and correction module performs corresponding operation according to the result of the tracing, for example, whether the current environment is a single test instrument environment or a multi-test instrument environment is judged according to the result of the tracing, and the judgment result is sent to the test instrument library dynamic loading module. And the test instrument library dynamic loading module is used for carrying out corresponding test instrument library loading operation according to the judgment result of the test script analysis and correction module. Specifically, when the test meter library dynamic loading module obtains the determination result that the test meter environment is currently a single test meter environment, the universal test meter API library and the underlying API library of the test meter are loaded into the global namespace. And when the dynamic loading module of the test instrument library acquires the judgment result of the current multi-test instrument environment, loading the universal test instrument API library and the bottom API library of the test instrument to the corresponding name space.
In summary, with the present invention, when the test instrument is changed, the test device of the present invention performs the corresponding test instrument library loading operation according to the input of the user. Thereby shielding the variability of the test meter. For a test engineer, the mode of calling the API layer of the universal test instrument in the multi-test instrument environment is consistent with the mode of calling the API layer of the universal test instrument in the single-test instrument environment, and only a corresponding test instrument object is created based on the API layer of the universal test instrument, and a corresponding method is called to operate the test instrument, and the method calls which corresponding test instrument is responsible for by the test script analysis and correction module and the test instrument library dynamic loading module. Therefore, the compiling efficiency and the universality of the test script are improved, and the test script is easy to maintain.
Drawings
FIG. 1 is a schematic diagram of the structure of the testing apparatus of the present invention;
FIG. 2 is a schematic diagram of the implementation flow of the testing method principle of the present invention;
FIG. 3 is a schematic diagram of the API hierarchy after adding the API layer of the universal test instrument according to the present invention;
fig. 4 is a schematic diagram of completing the tracing based on the hierarchical structure of the interface in the API layer of the universal test instrument in the multi-test instrument environment.
Detailed Description
The core idea of the invention is as follows: aiming at the API hierarchical architecture, the invention is different from the prior art, a universal test instrument API layer is added on the bottom API of the existing test instrument, and the test instrument API is uniformly developed and set on the universal test instrument API layer. The test device is different from the existing test device, and a test script analysis and correction module and a test instrument library dynamic loading module are added. By adopting the invention, the universality of the test script is improved, and the test script is prevented from being repeatedly written; but also shields the difference of the test instruments. Therefore, the testing efficiency is improved, and the research and development cost is reduced.
The following describes the embodiments in further detail with reference to the accompanying drawings.
As shown in fig. 1, the testing device based on the API of the universal testing instrument comprises a testing information input module 1, a testing device initialization module 2, a testing script analysis and modification module 3, a testing instrument library dynamic loading module 4 and a testing script interpretation and execution module 5.
The test information input module 1 is used for receiving information input by a user. Here, the information input by the user includes type information of the test meter, and test topology information composed of the test meter and the device under test. The test equipment initialization module 2 is used for updating the test script operation control file after initialization is carried out according to the information input by the user. Here, the initialization includes an operation of creating a namespace according to type information of the test meter input by the user. Here, the test script operation control file stores the relevant control information of the test script operation. After the test equipment initialization module 2 initializes according to the information input by the user, the test script analysis and correction module 3 is started to read all the test scripts.
The test script analysis and correction module 3 is used for reading all the test scripts, and then tracing the test actions of the control test instrument in the test scripts by calling the API layer of the universal test instrument and according to the hierarchical structure of the interface in the API layer of the universal test instrument; and then, the test script analysis and correction module 3 performs corresponding operation according to the tracing result. Here, for the trace-up, a hierarchy of interfaces in the API layer of the generic test instrument is constructed through abstraction of the test instrument, so as to perform the trace-up operation on the test instrument by using the hierarchy. Then, in the hierarchical structure, based on an interface corresponding to the test action, according to the logical level of the interface in the hierarchical structure, the operation from traversing the interface at the lower layer of the hierarchical structure to executing the top entity of the interface is the operation of tracing up. Here, the top level entity is the test meter. Here, the corresponding operations include: and after the test script analysis and correction module 3 generates a new test script, updating the test script operation control file. The corresponding operations further include: the test script analysis and correction module 3 judges whether the current environment is a single test instrument environment or a multi-test instrument environment according to the result of the tracing, and sends the judgment result to the test instrument library dynamic loading module 4.
The test instrument library dynamic loading module 4 is used for receiving the judgment result of the test script analysis and correction module 3 and then carrying out corresponding test instrument library loading operation. Specifically, when the test meter library dynamic loading module 4 obtains a determination result that the test meter environment is currently a single test meter environment, the universal test meter API library and the underlying API library of the test meter are loaded into the global namespace. And when the test instrument library dynamic loading module 4 acquires the judgment result of the current multi-test instrument environment, loading the universal test instrument API library and the bottom API library of the test instrument to the corresponding name space.
The test script interpretation and execution module 5 is configured to read the relevant control information of the test script operation in the test script operation control file, call the interpreter to interpret the loaded test script into executable code, such as JAVA code, and then execute the executable code on the test instrument.
As shown in fig. 2, a testing method based on a universal test instrument API includes the following steps:
In step 101, the test equipment initialization module reads the user input information for initialization, including an operation of creating a namespace according to the type information of the test meter input by the user. Here, the test script operation control file stores the relevant control information of the test script operation.
In step 101, the manner of constructing the hierarchical architecture of the API specifically includes: and adding a universal test instrument API layer on the bottom API of the existing test instrument.
Here, regarding the API hierarchy, as shown in fig. 3, fig. 3 is a schematic composition diagram of the API hierarchy after adding the API layer of the generic test meter according to the present invention. Included in fig. 3 are existing test meter bottom API11 and generic test meter API layer 22. And the generic test meter API layer 22 provides API clients of the upper layers for use. The bottom API11 of the existing test instrument includes four layers, which are, from bottom to top, a test instrument hardware layer 111, a hardware abstraction layer 112, a test instrument operating system layer 113, and a test instrument bottom function library layer 114. It should be noted here that the calling of the existing test meter underlying API11 through the generic test meter API layer 22 is done by the test meter control server. After receiving the call operation triggered by the API layer 22, the test meter control server calls the existing test meter bottom API11 to complete the call operation. And the test meter control server can also be provided for the graphical user interface client to use. The test meter underlying function library herein may also be understood as an underlying API library of the test meter.
The hardware abstraction layer is located between the test instrument hardware layer and the test instrument operating system layer, so the hardware abstraction layer is usually used for directly testing the instrument hardware layer downwards and providing a uniform interface for the test instrument operating system layer upwards. Thereby shielding the hardware diversity of the test meter. Then, with this type, since the added generic test meter API layer is located above the bottom API of the existing test meter, and is provided for the API client of the upper layer to use. And in the API layer of the universal test instrument, the test instrument API is uniformly developed and set. Therefore, the universal test instrument API layer is used for packaging the bottom API and providing a uniform interface for the operation of the test instrument for the upper API client side so as to complete the test of the test instrument on the tested equipment under the control of the test equipment. Thereby shielding the variability of the test meter.
Here, the corresponding operations include: and after the test script analysis and correction module generates a new test script according to the upper tracing result, updating the test script operation control file. The corresponding operations further include: the test script analysis and correction module judges whether the current environment is a single test instrument environment or a multi-test instrument environment according to the result of the tracing, and sends the judgment result to the test instrument library dynamic loading module, so that the subsequent test instrument library dynamic loading module can carry out corresponding test instrument library loading operation according to the judgment result.
Here, for the completion of the tracing of the hierarchical structure of the interface in the API layer of the universal test instrument, as shown in fig. 4, fig. 4 is a schematic diagram of the completion of the tracing based on the hierarchical structure of the interface in the API layer of the universal test instrument in the multi-test instrument environment of the present invention. FIG. 4 shows an example of a generic test meter API level object-oriented hierarchy, including test meter object 311 in FIG. 4; port object 321 and scheduler object 322; protocol emulation object 331, traffic routing engine object 332, and statistics analysis engine object 333. And the test meter object 311 is located at the top layer, the port object 321 and the scheduler object 322 are located at the middle layer, and the protocol simulation object 331, the traffic transmission engine object 332 and the statistical analysis engine object 333 are located at the bottom layer. Then, under the hierarchy, the dashed arrow in fig. 4 indicates that the trace-up operation from the interface at the lower level of the hierarchy to the top-level entity of the interface is completed from the lower level of the hierarchy, such as the protocol simulation object 331, to the test meter object 311 at the top level via the port object 321 at the middle level, that is, based on an interface corresponding to the test action, according to the logical level of the interface in the hierarchy. Here, the top level entity is the test meter. It should be noted here that the object of each layer is created by a class corresponding to the object of the upper layer, such as calling a method of a tester class to create a port object.
Fig. 4 shows an example of abstracting a test instrument from a logic level of software functions of the test instrument, and a hierarchy of interfaces in an API layer of a universal test instrument is constructed through abstracting the test instrument, so as to facilitate the trace-up operation of the test instrument by using the hierarchy. The concrete abstract process is as follows: the test meter is considered as a specific object. First, a test meter class corresponding to a test meter object is decomposed into a port class, a protocol emulation class, a traffic transmission engine class, and a statistical analysis engine class according to aggregation of classes. There are also other classes that assist in the operation of the test meter, such as a scheduler class and a scheduled event class. Then, the classes of the above-mentioned parts are hierarchically divided according to the generalization of the classes. For example, a specific port class is derived from a port class, and an inheritance relationship exists between the specific port class and the port class.
Then, for example, in the example of this generic test meter API level object oriented hierarchy, the process of creating a protocol simulation object is as follows:
a1, creating two test meter objects objTester1 and objTester 2.
a2, enabling objTester1 and objTester2 to respectively correspond to the two test meters, wherein the IP addresses of the two test meters are $ chassisAddr1 and $ chassisAddr2 respectively.
CTestDevice objTester1 $chassisAddr1；
CTestDevice objTester2 $chassisAddr2；
a3, calling a method of the tester meter class creates a port object.
objTester1 CreateTestPort-PortName objPort1；
objTester2 CreateTestPort-PortName objPort2；
a4, calling the method of the port class to create the protocol emulation object.
objPort1 CreateRouter-RouterName objRouter1；
objPort2 CreateRouter-RouterName objRouter2；
The above test actions of the control test meter can be traced back to the top-level entity performing the test action, i.e. the test meter entity, as indicated by the dashed arrow in fig. 4. In this embodiment, objPort1 createtrouter can go up to the test meter object objTester1 which performs this test action, and objPort2 createtrouter can go up to the test meter object objTester2 which performs this test action.
In addition to the example concrete abstraction process given in fig. 4, another embodiment of the generic test meter API layer oriented object hierarchy has the concrete abstraction process: the test instrument is regarded as a concrete object to be abstracted, and the abstracted class comprises a port class, a concrete port class, a protocol simulation class and a concrete protocol simulation class. These classes are in a parallel relationship and are implemented based on object-oriented methods only. Compared with the concrete abstraction process of the example given in fig. 4, the abstraction process has unclear class hierarchy division of the above parts, and is not beneficial to improving the development efficiency of the test script and maintaining the test script.
And 103, after the test script analysis and correction module judges according to the upper tracing result, the test instrument library dynamic loading module acquires the judgment result from the test script analysis and correction module and carries out corresponding test instrument library loading operation.
Here, the test meter library loading operation includes two cases. In the first case, when the test instrument library dynamic loading module obtains the judgment result that the test instrument library is currently in the single test instrument environment, the universal test instrument API library and the bottom API library of the test instrument are loaded to the global name space. And in the second situation, when the dynamic loading module of the test instrument library acquires the judgment result of the multi-test instrument environment, loading the universal test instrument API library and the bottom API library of the test instrument to the corresponding name space.
The following description is given to a specific implementation process of step 102, as an example. The specific implementation process of step 102 includes the following steps:
step 201, the test script analyzing and correcting module reads all the test scripts and reads each test action in the test scripts in sequence.
Here, reading each test action in the test script is completed by calling the API layer of the universal test instrument and tracing the test action of the control test instrument in the test script according to the hierarchical structure of the interface in the API layer of the universal test instrument.
Step 202, judging whether the current test action is a control action on the tester, if so, executing step 203; otherwise, go to step 205.
Step 203, constructing a hierarchical structure of an interface in the API layer of the universal test instrument according to the principle of the concrete abstract process of the example given in fig. 4, and performing an up-tracking operation on the test action of the control test instrument in the test script according to the hierarchical structure.
Here, the principle of the concrete abstraction process of the example given in fig. 4 is to treat the test meter as a concrete object. First, the test meter classes corresponding to the test meter object are decomposed according to the aggregation of the classes, and then the decomposed parts are hierarchically divided according to the generalization of the classes.
Here, the trace-up operation starts from the underlying interface until traversing to the final execution entity, i.e., the test meter, which executes the test action.
Step 204, judging whether the execution entity exists in the final execution entity list, if not, writing the execution entity into the final execution entity list, and adding 1 to the final execution entity number to execute step 205; otherwise, step 205 is performed directly.
Step 205, judging whether the current test script is analyzed and finished, if so, executing step 206; otherwise, go to step 202.
Step 206, judging whether the test script is applied to the multi-test-meter environment according to the result of the tracing, namely judging whether the final number of the executed entities is greater than 1, if so, creating a new test script, adding a corresponding name space to the method call of the test meter in the original test script, and then executing step 207; otherwise, step 208 is performed.
Here, the method call to the test meter in the original test script is added with the corresponding namespace, for example.
The test actions in the original test script are as follows:
CTestDevice objTester1 $chassisAddr1；
CTestDevice objTester2 $chassisAddr2；
the test actions in the created new test script are as follows:
::TESTER1::CTestDevice objTester1 $chassisAddr1；
::TESTER2::TestDevice objTester2 $chassisAddr2；
the namespace then maps to the type information of the test meter entered by the user in the test information entry module, thus shielding the test engineer from variability in the type of test meter. And no namespace is needed if the method calls to create the object.
And step 207, updating the test script operation control file, and updating the relevant control information of the test script operation applied to the multi-test instrument environment into the relevant control information of the newly created test script operation. And finally, the test script analysis and correction module executes the newly created test script.
Step 208, judging whether all the test scripts are analyzed and finished, if so, finishing the analysis and correction process of the current test script analysis and correction module; otherwise, go to step 201.
The following description is given to a specific implementation process of step 103, taking an example. The specific implementation process of step 103 is as follows:
judging whether the test script is applied to the environment of the multiple test instruments according to the final number of the execution entities obtained by the test script analysis and correction module, namely judging whether the final number of the execution entities is more than 1; if so, then the multi-test meter environment is present, then the generic test meter API library and the underlying API library of the test meter are loaded into the corresponding namespace. Such as the generic test meter API library that loads the test meter Tester1 and the underlying API library of the test meter to the Tester1 namespace; or the generic test meter API library of the test meter Tester2 and the underlying API library of the test meter to the Tester2 namespace. If not, the environment is the single test instrument environment, the universal test instrument API library and the bottom API library of the test instrument are loaded to the global name space, and therefore the test under the single test instrument environment is compatible.
The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention.
Claims (8)
1. A test device based on universal test instrument application programming interface, the test device includes test information input module, test device initialization module, and test script explain execution module, characterized by that, the device also includes test script analysis and revise module, and test instrument library dynamic loading module; wherein,
the test script analysis and correction module is used for calling an Application Programming Interface (API) layer of the universal test instrument after reading all the test scripts and tracing the test action of the control test instrument in the test script according to the hierarchical structure of the interface in the API layer of the universal test instrument; wherein the universal test meter API layer is positioned above the bottom API layer of the existing test meter;
and the test instrument library dynamic loading module is used for obtaining a judgment result from the test script analysis and correction module after the test script analysis and correction module judges according to the upper tracing result, and carrying out corresponding test instrument library loading operation.
2. The test equipment of claim 1, wherein the test meter library dynamic loading module is further configured to obtain a determination result that the test meter environment is currently a single test meter environment, and load the universal test meter API library and the underlying API library of the test meter into the global namespace.
3. The test equipment as claimed in claim 1, wherein the test meter library dynamic loading module is further configured to obtain a determination result that is currently more than one test meter environment, and load the API library of the generic test meter and the API library of the test meter into the corresponding name space.
4. A testing method based on a universal testing instrument application programming interface is characterized by comprising the following steps:
A. constructing a hierarchical architecture of an API and a hierarchical structure of an interface in an API layer of a universal test instrument; after the test script analysis and correction module reads all the test scripts, the test action of the control test instrument in the test script is traced up by calling the API layer of the universal test instrument and according to the hierarchical structure of the interface in the API layer of the universal test instrument; wherein the universal test meter API layer is positioned above the bottom API layer of the existing test meter;
B. and after the test script analysis and correction module judges according to the upper tracing result, obtaining a judgment result from the test script analysis and correction module, and carrying out corresponding test instrument library loading operation.
5. The testing method according to claim 4, wherein in the step a, the manner of constructing the hierarchical architecture of the API specifically includes: and adding a universal test instrument API layer on the bottom API of the test instrument.
6. The method of claim 4, further comprising, after step B:
C. after the test script interpretation and execution module reads the relevant control information of the test script operation in the test script operation control file, the loaded test script is interpreted into an executable code by calling an interpreter, and then the executable code is executed on the test instrument.
7. The test method according to any one of claims 4 to 6, wherein in the step B, the loading operation of the corresponding test instrument library is specifically: and when the test instrument library dynamic loading module acquires the judgment result of the single test instrument environment, loading the universal test instrument API library and the bottom API library of the test instrument into the global name space.
8. The test method according to any one of claims 4 to 6, wherein in the step B, the loading operation of the corresponding test instrument library is specifically: and when the test instrument library dynamic loading module acquires the judgment result of more than one test instrument environment, loading the universal test instrument API library and the bottom API library of the test instrument to the corresponding name space.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101008147A CN101247292B (en) | 2008-02-22 | 2008-02-22 | Test equipment and method based on universal test meter API |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101008147A CN101247292B (en) | 2008-02-22 | 2008-02-22 | Test equipment and method based on universal test meter API |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101247292A CN101247292A (en) | 2008-08-20 |
| CN101247292B true CN101247292B (en) | 2011-08-10 |
Family
ID=39947518
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2008101008147A Active CN101247292B (en) | 2008-02-22 | 2008-02-22 | Test equipment and method based on universal test meter API |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101247292B (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104796797B (en) * | 2014-01-16 | 2018-11-20 | 深圳市双翼科技有限公司 | The back-stage management method and device of optical line terminal |
| CN104615534B (en) * | 2015-01-28 | 2017-08-01 | 广州酷狗计算机科技有限公司 | interface test method and device |
| CN106325117B (en) * | 2015-06-30 | 2020-04-10 | 中兴通讯股份有限公司 | Method, device and system for automatically controlling instrument |
| CN105162664B (en) * | 2015-09-29 | 2019-06-25 | 上海斐讯数据通信技术有限公司 | A kind of automation platform test method and system based on the exploitation of instrument middle layer |
| WO2017062008A1 (en) * | 2015-10-08 | 2017-04-13 | Hewlett Packard Enterprise Development Lp | Comparing scripts |
| US10592370B2 (en) * | 2017-04-28 | 2020-03-17 | Advantest Corporation | User control of automated test features with software application programming interface (API) |
| CN108319516B (en) * | 2017-12-28 | 2021-11-23 | 上海科梁信息科技股份有限公司 | Test system and test method |
| CN109656622A (en) * | 2018-12-04 | 2019-04-19 | 安徽皖通邮电股份有限公司 | A kind of packaging method for realizing network tester in communication equipment automatic test |
| CN111130927B (en) * | 2019-12-04 | 2021-12-17 | 中国电子科技集团公司第三十研究所 | Method for automatically realizing service test of network layer communication terminal equipment |
| CN112285545B (en) * | 2020-10-14 | 2021-06-04 | 江门市电力工程输变电有限公司 | GIS disconnecting switch opening and closing test method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1963782A (en) * | 2006-11-28 | 2007-05-16 | 北京中星微电子有限公司 | Method and system for testing embeded file system |
| CN101025686A (en) * | 2007-03-22 | 2007-08-29 | 中兴通讯股份有限公司 | Automation test system and test script generating and operating method |
-
2008
- 2008-02-22 CN CN2008101008147A patent/CN101247292B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1963782A (en) * | 2006-11-28 | 2007-05-16 | 北京中星微电子有限公司 | Method and system for testing embeded file system |
| CN101025686A (en) * | 2007-03-22 | 2007-08-29 | 中兴通讯股份有限公司 | Automation test system and test script generating and operating method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101247292A (en) | 2008-08-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101247292B (en) | Test equipment and method based on universal test meter API | |
| JP4950454B2 (en) | Stack hierarchy for test automation | |
| EP1089172A2 (en) | Compiler and method for compiling specification language into implementation language | |
| US20020133807A1 (en) | Automation and isolation of software component testing | |
| CN103970659B (en) | Android application software automation testing method based on pile pitching technology | |
| US20090210862A1 (en) | Intelligent computer program debugger, and system and method for implementing the same | |
| CN110515848B (en) | Automatic test system and automatic test method | |
| KR20140072726A (en) | Function Test Apparatus based on Unit Test Cases Reusing and Function Test Method thereof | |
| Nguyen et al. | A goal-oriented software testing methodology | |
| Zhou et al. | Towards a practical approach to test aspect-oriented software | |
| US20070214178A1 (en) | Multi-project verification environment | |
| CN114818565A (en) | Simulation environment management platform, method, equipment and medium based on python | |
| Tierno et al. | Open issues for the automotive software testing | |
| US6430705B1 (en) | Method for utilizing virtual hardware descriptions to allow for multi-processor debugging in environments using varying processor revision levels | |
| CN107124236A (en) | A kind of receiver performance indication test method based on script | |
| Usaola et al. | An architecture for the development of mutation operators | |
| Pezze et al. | Testing object-oriented software | |
| Alexander et al. | Coupling-based Testing of OO Programs. | |
| CN101183400A (en) | Debugging and checking method and system in graph hardware design | |
| CN113220586A (en) | Automatic interface pressure test execution method, device and system | |
| US6385740B1 (en) | Method to dynamically change microprocessor test software to reflect different silicon revision levels | |
| US20090007068A1 (en) | Accessing Non-Public Code | |
| Delamaro et al. | Structural testing of mobile agents | |
| Corriveau | Testable requirements for offshore outsourcing | |
| Orjala | Unit testing methods for Internet of Things Mbed OS operating system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |