CN118626400B - Software testing system for core framework - Google Patents

Abstract

The invention belongs to the technical field of testing, and more particularly relates to a software testing system for a core framework, wherein the invention enables each component to be independently started through a program by modifying the configuration of an xml starting file, so that the invention can determine the quantity of the starting components according to different testing components during testing, can effectively reduce the resource occupation during testing, and can send executable files served by a file system to a server through a client through CORBA, and then the client organizes execution parameters according to the executable files and sends the execution parameters to the server through CORBA, and the server creates a process based on the received executable files and the execution parameters and executes the executable files with the execution parameters based on the created process; so that the test can be started by only typing in a command once through the client; based on the method, the unit testing system which is wide in coverage, strong in pertinence and completely independent is provided.

Description

A software testing system for core framework

Technical Field

The invention belongs to the field of testing technology, and more specifically, relates to a software testing system for a core framework.

Background Art

The CF (Core Framework) core framework is a set of infrastructure for implementing the SCA specification. It defines the basic elements, interfaces and services required to build, integrate and manage software radio systems. It aims to achieve a highly modular, configurable and extensible software radio system. CF uses the design concept of separating software and hardware to enable radio functions to adapt to changing communication technologies and standards through software updates.

Unit testing, also known as module testing, is a test that verifies the correctness of program modules. It can check and verify the smallest testable unit in the software in isolation from other parts of the program. In procedural programming, a unit test is a single program, function, or process. Unit testing is performed in an automated manner, so performing unit testing in a large number of regression testing scenarios can improve testing efficiency.

The current CF components are constantly updated and iterated over time, including domain managers, device managers, application factories, applications, and various services. Each component upgrade may be accompanied by different problems: incompatibility with other components, asynchronous updates between components, incompatibility between components and platforms, etc. Therefore, the current core framework urgently needs a unit test system with wide coverage, strong pertinence, and complete independence to help developers find bugs in the development process.

Summary of the invention

The present invention provides a software testing system for a core framework, and intends to provide a unit testing system with wide coverage, strong pertinence, and complete independence.

A software testing system for the core framework, including a server and a client;

A simulation device is built in the client, and the simulation device only includes basic parameters and basic initialization and release functions;

The client sends the executable file of the file system service to the server through CORBA, and then the client organizes execution parameters according to the executable file, and sends the execution parameters to the server through CORBA, the server creates a process based on the received executable file and execution parameters, and executes the executable file with the execution parameters based on the created process;

Each execution file corresponds to a test item, and the test components corresponding to each test item are configured by modifying the XML startup file so that each component is started independently through the program.

The present invention modifies the startup file configuration of xml so that each component is independently started through a program. Therefore, the present invention determines the number of startup components according to the difference of the test components during testing, which can effectively reduce the resource occupation during testing. The client sends the executable file of the file system service to the server through CORBA, and then the client organizes the execution parameters according to the executable file, and sends the execution parameters to the server through CORBA. The server creates a process based on the received executable file and the execution parameters, and executes the executable file with the execution parameters based on the created process. Therefore, the test can be started by typing a command once through the client. Based on this, a unit test system with wide coverage, strong pertinence and complete independence is provided.

Preferably, the server and the client establish communication based on an object reference identifier (IOR) or CORBALOC;

After the server is started, it generates an IOR for connection. The client directly connects to the server IP by obtaining the IOR or starting CORBALOC communication on the server.

Preferably, the server includes a file transfer module, a lightweight executable device module and a COBRA server module;

The lightweight executable device module includes an execution unit (execue unit), a termination unit (terminate unit), a loading unit (load unit) and an unloading unit (unload unit).

Preferably, the client includes a CF component startup configuration module, a file transfer and lightweight executable device module, and an oe environment abnormality judgment module;

The CF component startup configuration module is used to initialize parameter configuration;

The file transfer and lightweight executable device module is used to start the component to be tested;

The oe environment abnormality judgment module is used to judge whether the data received by the client is abnormal.

Preferably, the CF component startup configuration module constructs a component class for each component, and the component class stores information of the corresponding component;

Based on the CF component startup configuration module, each component is configured before startup.

Preferably, the CF component startup configuration module performs configuration on each component before startup, including: XML file parsing, startup parameter setting, and adding class pointers to the Testpart initialization configuration to perform unified component initialization;

During the initialization process, the initialized data is returned to the class object of the instance in the test item. After all configurations are completed, unified component initialization is performed. The Testpart initialization configuration executes the initialization function of each added class pointer one by one.

Preferably, the client includes a CF unit test framework; the CF unit test framework integrates test items;

When testing is required, the CF unit test framework sends different test resource files according to different unit test items; the server starts the corresponding component for component testing according to the test resource files and commands sent by the client's CF unit test framework.

Preferably, the test resource files include: XML files, dtd files, executable files of each component and server files required for testing.

The beneficial effects of the present invention include at least:

The present invention modifies the startup file configuration of xml so that each component is independently started through a program. Therefore, the present invention determines the number of startup components according to the difference of the test components during testing, which can effectively reduce the resource occupation during testing. The client sends the executable file of the file system service to the server through CORBA, and then the client organizes the execution parameters according to the executable file, and sends the execution parameters to the server through CORBA. The server creates a process based on the received executable file and the execution parameters, and executes the executable file with the execution parameters based on the created process. Therefore, the test can be started by typing a command once through the client. Based on this, a unit test system with wide coverage, strong pertinence and complete independence is provided.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

FIG. 1 is a system framework diagram provided by an embodiment of the present invention.

DETAILED DESCRIPTION

In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

As shown in FIG1 , a software testing system for a core framework includes a server and a client;

A simulation device is built in the client, and the simulation device only includes basic parameters and basic initialization and release functions;

The client sends the executable file of the file system service to the server through CORBA, and then the client organizes execution parameters according to the executable file, and sends the execution parameters to the server through CORBA, the server creates a process based on the received executable file and execution parameters, and executes the executable file with the execution parameters based on the created process;

Each execution file corresponds to a test item, and the test components corresponding to each test item are configured by modifying the XML startup file so that each component is started independently through the program.

The present invention modifies the startup file configuration of xml so that each component is independently started through a program. Therefore, the present invention determines the number of startup components according to the difference of the test components during testing, which can effectively reduce the resource occupation during testing. The client sends the executable file of the file system service to the server through CORBA, and then the client organizes the execution parameters according to the executable file, and sends the execution parameters to the server through CORBA. The server creates a process based on the received executable file and the execution parameters, and executes the executable file with the execution parameters based on the created process. Therefore, the test can be started by typing a command once through the client. Based on this, a unit test system with wide coverage, strong pertinence and complete independence is provided.

As a possible implementation of this embodiment, the server and the client establish communication based on IOR or CORBALOC;

After the server is started, it generates an IOR for connection. The client directly connects to the server IP by obtaining the IOR or starting CORBALOC communication on the server.

As a possible implementation of this embodiment, the server includes a file transfer module, a lightweight executable device module and a COBRA server module;

The lightweight executable device module includes an execute unit, a terminate unit, a load unit and an unload unit.

As a possible implementation of this embodiment, the client includes a CF component startup configuration module, a file transfer and lightweight executable device module, and an oe environment abnormality judgment module;

The CF component startup configuration module is used to initialize parameter configuration;

The file transfer and lightweight executable device module is used to start the component to be tested; based on the client, the relevant executable files and startup parameters are sorted out, and the executable files are loaded to the server through the load unit. The client calls the execue unit and transmits the startup parameters to the server through the execue unit. After the server receives the startup parameters, it calls the process startup function of the target component system; for example: fork and execv of the Linux system, fork creates a process, execv loads executable files and startup parameters, and the purpose of remotely starting the process is achieved based on this. After execution, the client calls the terminate unit to terminate the process started by the server, and finally calls the unload unit to unload the file loaded by the server.

The oe environment exception judgment module is used to judge whether the data received by the client is abnormal. If the server runs an exception during the execution of the test item, the server will pass the exception information to the client through CORBA, and the client will then capture the relevant exception (try, catch) through the oe environment exception judgment; if it is a manufactured exception, the test item will be carried out smoothly; if it is an unmanufactured exception, the exception will be printed and the program will end.

Preferably, the CF component startup configuration module constructs a component class for each component, and the component class stores information of the corresponding component;

Preferably, the CF component startup configuration module performs configuration on each component before startup, including: XML file parsing, startup parameter setting, and adding class pointers to the Testpart initialization configuration to perform unified component initialization;

The client has its own set of component configuration information classes, which are inherited from the parent class Testpart; for example, the DomainManager class, whose class members store the information of dmd.xml; the class member functions have functions specifically for initialization and termination. When initializing a class, its own class pointer is stored in the dynamic array of the parent class. Finally, the parent class calls the initialization function for unified initialization. Since the initialization function of the parent class is a virtual function, it will enter the initialization function of the child class and then perform a series of initialization operations.

During the initialization process, the initialized data is returned to the class object of the instance in the test item. After all configurations are completed, unified component initialization is performed. The Testpart initialization configuration executes the initialization function of each added class pointer one by one.

The class declares an object in the test item, and then the test item calls the virtual function of the parent class TestPart to execute the subclass initialization function; therefore, you can access initialized public data through the class object, or access private member data through public member functions.

These initialization configurations are the initialization of the client, while the TestPart initialization configuration is the client telling the server how to start the component. For example, the initialization of the client DomainManager tells the server how to start the domain manager component. All components constitute the CF platform.

Exemplary:

The first step is to initialize the class and assign values to private members. The second step is to parse the dmd file and add the parsed spd, scd and dtd files and the domain manager executable file to the Testpart initialization configuration. The third step is to set the startup parameters of the domain manager and add them to the custom Testpart initialization configuration. The initialized data will be returned to the test item that calls it. After all configurations are completed, the unified component initialization will be performed. The Testpart initialization configuration will execute each added initialization configuration one by one. For the domain manager, the parsed file is sent to the server, and then the startup parameters are sent. Finally, the client calls the execute of the file transfer and lightweight executable device module to let the server start the domain manager component.

As a possible implementation of this embodiment, the client includes a CF unit test framework; the CF unit test framework integrates test items;

When testing is required, the CF unit test framework sends different test resource files according to different unit test items; the server starts the corresponding component for component testing according to the test resource files and commands sent by the client's CF unit test framework.

As a possible implementation of this embodiment, the test resource file includes: an XML file, a dtd file, executable files of each component, and a server-side file required for the test.

Based on this embodiment, when testing the file system, the client sends the executable file of the file system service to the server through CORBA, and then the client organizes the execution parameters and sends them to the server again. After receiving the data, the server will create a process to execute the executable file of the file system service with parameters; the client obtains the command service of the file system through the domain manager, thereby performing CORBA communication with the server file system;

Traditional model deployment will start all components at once, including the domain manager, device manager, devices, applications, etc.; however, if you want to test a single component, you do not need to start all components. Therefore, the components required for each test item are designed independently, that is, by modifying the XML startup file configuration, each component is started independently through the program, and there is no need to start multiple components to occupy program resources during testing; for example, when testing the manager component, the program only needs to start the domain manager, and no longer starts the device manager and application, which can greatly reduce the startup time.

When testing devices, traditional devices are created and produced in modeling software, and this embodiment takes this point into consideration during design. Therefore, in the client's CF file transfer and startup framework, a simulation device without an entity is constructed, which is only used as an empty device for testing. It has the basic parameters of the device, including identifier and profile, but no other functions, nor does it have a complete executable file like other devices. It only exists in the client and has the most basic initialization release like other CF component startup configurations. For example, when testing the installation and uninstallation of the device manager, there is no need to know the function of the device, only the device ID is needed. This operation can reduce resource usage during testing and speed up testing.

In addition, in this embodiment, each test item in the CF unit test framework is independent, and its success or failure will not affect the progress of other test items; moreover, each test item will deploy the model separately and close it after the test is completed, thus avoiding the change or stop of the model due to a certain test, which will hinder other tests.

In summary, compared with traditional tests, the present invention determines the number of startup components according to the different test components, which can effectively reduce the resource usage during testing. In addition, all tests are automated tests. After starting the program, you only need to type a command once to start the test. After the test is completed, the program prints the success and failure items of the test, and each error item also records the program location where the error occurs and the error code, which is convenient for developers to view.

The server and the client are isolated. You only need to put the server on the target platform and start the client on the PC to perform the test. You no longer need to put the various components and XML files required for the test on the server. All files are sent to the server through the client, which fundamentally solves the problem of testing being unable to proceed due to different server models.

The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims (7)

1. The software testing system for the core framework is characterized by comprising a server side and a client side;

The client is internally provided with simulation equipment serving as empty equipment used in the test;

The client sends the executable file of the file system service to the server through CORBA, the client organizes the execution parameters according to the executable file, the execution parameters are sent to the server through CORBA, the server creates a process based on the received executable file and the execution parameters, and the executable file with the execution parameters is executed based on the created process;

each execution file corresponds to one test item, and each test component corresponding to each test item is independently started through a program by modifying the configuration of the xml starting file;

The client comprises a CF unit test framework; the CF unit test frame is integrated with test items;

when the test is required, the CF unit test framework transmits different test resource files according to different unit test items; and the server starts the corresponding component to perform component test according to the test resource file and the command sent by the CF unit test framework of the client.

2. The software testing system for a core framework of claim 1, wherein the server and client establish communication based on an object reference identifier or CORBALOC;

The client generates an object reference identifier for connection after the server is started, and the client directly connects with the server IP by acquiring the object reference identifier or after the server is started CORBALOC for communication.

3. The software testing system for a core framework of claim 1, wherein the server comprises a file transfer module, a lightweight executable device module, and a COBRA server module;

The lightweight executable equipment module comprises an execution unit, a termination unit, a loading unit and an unloading unit.

4. The software testing system for a core framework of claim 1, wherein the client comprises a CF component start configuration module, a file transfer and lightweight executable device module, and an oe environment anomaly determination module;

The CF component starting configuration module is used for initializing parameter configuration;

the file transmission and lightweight executable equipment module is used for starting the component to be tested;

the oe environment abnormality judging module is used for judging whether the data received by the client is abnormal or not.

5. The system according to claim 4, wherein the CF component start configuration module constructs a component class for each component, and the component class stores information of the corresponding component;

and configuring each component before starting based on the CF component starting configuration module.

6. The software testing system for a core framework of claim 5, wherein said CF component start-up configuration module pre-start-up configuration of each component comprises: xml file analysis, starting parameter setting, class pointer adding to Testpart initialization configuration to perform unified component initialization;

in the initialization process, the initialized data is returned to class objects of the examples in the test item, unified component initialization is carried out after all the configuration is completed, and Testpart initialization configuration executes the initialization function of each added class pointer one by one.

7. A software testing system for a core framework according to claim 1, wherein said test resource file comprises: XML file, dtd file, executable file of each component, and server side file required for testing.