Test methods and apparatus for base stations, storage media and electronic devices

Abstract

This application discloses a base station testing method, apparatus, storage medium, and electronic device. The method includes: selecting a target test item matching the target base station from various test items stored in a test item library of the test equipment based on reference base station information of the target base station; searching for a target configuration file matching the target test item from various configuration files stored in the test item library based on the target service information of the target base station, wherein the target service information characterizes the handling method of the supported services by the target base station, and the target configuration file characterizes the operation method of multiple test cases included in the target test item; and testing the target base station based on the target configuration file and the target test item. By adopting the above technical solution, the technical problem of low testing efficiency for base stations in related technologies is solved, achieving the technical effect of improving the testing efficiency of base stations.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a test method and apparatus for a base station, a storage medium, and an electronic device. Background Technology

[0002] In related technologies, when facing base station testing requirements, it is generally necessary to manually input commands from a large number of test files to specify the test files to be executed and the test configuration files. However, this testing method relies on the testing experience of the testers and is prone to situations where the specified test files or configuration files do not match the test requirements, or the test files and configuration files do not match, resulting in low efficiency in base station testing.

[0003] There is still no effective solution to the problem of low testing efficiency for base stations in related technologies. Summary of the Invention

[0004] This application provides a base station testing method and apparatus, storage medium and electronic device, to at least solve the problems of low testing efficiency of base stations in related technologies.

[0005] According to one embodiment of this application, a base station testing method is provided, applied to a test device for a target base station. The method includes: selecting a target test project matching the target base station from various test projects stored in a test project library of the test device based on reference base station information of the target base station, wherein the reference base station information is used to indicate the services supported by the target base station, and different test projects are used to test base stations supporting different services; searching for a target configuration file of the target test project matching the target base station from various configuration files stored in the test project library based on the target service information of the target base station, wherein the target service information is used to characterize the handling method of the supported services by the target base station, and the target configuration file is used to characterize the operation mode of multiple test cases included in the target test project, each test case being used to perform service testing on a service function of the base station; and testing the target base station according to the target configuration file and the target test project.

[0006] Optionally, based on the reference base station information of the target base station, target test items matching the target base station are selected from the various test items stored in the test item library of the test equipment. This includes: constructing a project sub-library based on the test file set of the test equipment, wherein the project sub-library is used to store available test items that can be executed, and the test file set stores the files used by the test equipment during the test execution process. The test item library includes the project sub-library; and selecting target test items that can be used to test the target base station from the available test items stored in the project sub-library based on the reference base station information.

[0007] Optionally, a project sub-library is constructed based on the test file set of the test equipment, including: traversing the file directory of the test file set to find subdirectories with target identifiers, where the target identifier is used to identify test projects; extracting the files corresponding to the subdirectories to obtain candidate test projects; filtering available test projects from each candidate test project based on the directory information, composition information, and execution information of each candidate test project, where the directory information indicates the directory hierarchy of the subdirectory corresponding to the candidate test project in the file directory, the composition information indicates the test script file settings at the target location in the subdirectory corresponding to the candidate test project, and the execution information indicates whether the test script file includes executable test cases; and storing the available test projects to obtain the project sub-library.

[0008] Optionally, available test projects are selected from each candidate test project based on the directory information, composition information, and execution information of each candidate test project. This includes: checking whether the directory information of each candidate test project meets the directory condition, checking whether the composition information of each candidate test project meets the composition condition, and checking whether the execution information of each candidate test project meets the execution condition. The directory condition is that the directory level of the subdirectory corresponding to the test project is a first-level subdirectory; the composition condition is that the root directory of the subdirectory corresponding to the test project includes at least one test script file; and the execution condition is that the test script file in the test project includes executable test cases. If it is detected that the directory information of the candidate test project meets the directory condition, the composition information of the candidate test project meets the composition condition, and the execution information of the candidate test project meets the execution condition, the candidate test project is determined as an available test project.

[0009] Optionally, the process involves selecting target test projects that support testing the target base station from the available test projects stored in the project sub-library based on the reference base station information. This includes: reading each available test suite from the available test projects in the project sub-library; selecting candidate test suites that match the target base station from each available test suite based on the reference base station information and the operation information of each available test suite, thus obtaining a correspondence between available test projects and candidate test suites, wherein the operation information indicates the base station service tested by the available test suites; displaying the correspondence between available test projects and candidate test suites, as well as the test cases included in each candidate test suite, on the user interface; and, in response to the selection of a reference test project in the available test projects, the selection of a reference test suite in the reference test projects, and the selection of reference test cases in the reference test suites, determining the test suites including the reference test cases as the target test suites, and determining the test projects including the target test suites as the target test projects.

[0010] Optionally, based on the target service information of the target base station, the target configuration file of the target test project matching the target base station is searched from the various configuration files stored in the test project library. This includes: obtaining the default configuration file of the target test project, wherein the default configuration file includes configuration parameters with corresponding relationships and a first configuration value; updating the configuration values ​​of the configuration parameters in the default configuration file with the second configuration values ​​of each configuration parameter obtained from the external configuration file to obtain an intermediate configuration file, wherein the external configuration file is the configuration file used by the test target base station specified by the user; updating the configuration values ​​of the configuration parameters in the intermediate configuration file with the third configuration values ​​of each configuration parameter obtained from the user interface to obtain a candidate configuration file; detecting the matching parameters between the candidate configuration file and the target service information, wherein the matching parameters are used to indicate the degree of matching between the candidate configuration file and the target service information; and determining the candidate configuration file as the target configuration file if the matching parameters are greater than the matching parameter threshold.

[0011] Optionally, detecting the matching parameters between the candidate configuration file and the target service information includes: extracting a set of configuration parameters from the candidate configuration file, wherein the set of configuration parameters includes at least the base station model parameters, base station software version parameters, base station management address parameters, and base station test scenario parameters supported by the candidate configuration file; the base station management address parameters are used to connect to the base station; and the base station test scenario parameters are used to indicate the test environment conditions that need to be met during the testing of the base station; detecting the degree of matching between the configuration values ​​of each configuration parameter included in the set of configuration parameters and the parameter values ​​of each operating parameter included in the set of operating parameters of the target base station, obtaining each intermediate matching value, wherein the target service information includes a set of operating parameters, which includes at least the base station model parameters, base station software version parameters, base station management address parameters, and base station operating scenario parameters of the target base station; and determining the matching parameters based on each intermediate matching value.

[0012] According to another embodiment of the present application, a base station testing apparatus is also provided. This apparatus is applied to a test device for a target base station. The apparatus includes: a filtering module, configured to filter target test items matching the target base station from various test items stored in the test item library of the test device based on reference base station information of the target base station, wherein the reference base station information is used to indicate the services supported by the target base station, and different test items are used to test base stations supporting different services; a searching module, configured to search for a target configuration file matching the target test item from various configuration files stored in the test item library based on target service information of the target base station, wherein the target service information is used to characterize the handling method of the supported services by the target base station, and the target configuration file is used to characterize the operation method of multiple test cases included in the target test item, each test case being used to perform service testing on a service function of the base station; and a testing module, configured to test the target base station according to the target configuration file and the target test item.

[0013] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the test method of the base station described above when it is run.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the test method of the base station through the computer program.

[0015] In this embodiment, the test equipment for the target base station selects target test projects matching the target base station from various test projects stored in the test project library based on reference base station information indicating the services supported by the target base station. Based on target service information characterizing the handling method of the supported services by the target base station, it searches for target configuration files matching the target test project from various configuration files stored in the test project library. The target configuration file characterizes the operation mode of multiple test cases included in the target test project. Testing the target base station based on the target configuration file and the target test project achieves automated matching of the base station's test files and configuration files, avoiding mismatches between the base station and the test files or configuration files. Therefore, it solves the technical problem of low testing efficiency for base stations in related technologies, achieving the technical effect of improving the testing efficiency of base stations. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the hardware environment for a base station testing method according to an embodiment of this application;

[0019] Figure 2 This is a flowchart of a base station testing method according to an embodiment of this application. Figure 1 ;

[0020] Figure 3 This is a schematic diagram of a user interface according to an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of an automated base station testing system according to an embodiment of this application;

[0022] Figure 5 This is a flowchart of a base station testing method according to an embodiment of this application. Figure 2 ;

[0023] Figure 6 This is an architecture diagram of a base station testing method according to an embodiment of this application;

[0024] Figure 7 This is a structural block diagram of a base station testing device according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] The methods and embodiments provided in this application can be executed on a computer terminal, device terminal, or similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a schematic diagram of the hardware environment for a base station testing method according to an embodiment of this application. Figure 1 As shown, a computer terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. In one exemplary embodiment, the computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 1 The more or fewer components shown, or having the same Figure 1 Equivalent functions or ratios shown Figure 1 The functions shown have more different configurations.

[0028] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the base station testing method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0029] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0030] This embodiment provides a base station testing method, which can be applied to the aforementioned computer terminal, or may also be applied to, but is not limited to, testing equipment for the target base station. Figure 2 This is a flowchart of a base station testing method according to an embodiment of this application. Figure 1 ,like Figure 2 As shown, the method may include, but is not limited to, the following steps:

[0031] Step S202: Select the target test item that matches the target base station from the test item library stored in the test item library of the test equipment according to the reference base station information of the target base station. The reference base station information is used to indicate the services supported by the target base station, and different test items are used to test base stations that support different services.

[0032] Step S204: Based on the target service information of the target base station, search for the target configuration file of the target test project that matches the target base station from the various configuration files stored in the test project library. The target service information is used to characterize the way the target base station handles the supported services, and the target configuration file is used to characterize the operation mode of multiple test cases included in the target test project. Each test case is used to perform service testing on one of the base station's service functions.

[0033] Step S206: Test the target base station according to the target configuration file and target test items.

[0034] Through the above steps, the test equipment for the target base station selects target test items matching the target base station from various test items stored in the test item library based on reference base station information indicating the services supported by the target base station. Then, based on target service information characterizing the handling methods of the supported services by the target base station, it searches for target configuration files matching the target test items from various configuration files stored in the test item library. The target configuration file characterizes the execution mode of the multiple test cases included in the target test item. Testing the target base station based on the target configuration file and the target test item achieves automated matching of the base station's test files and configuration files, avoiding mismatches between the base station and the test files or configuration files. Therefore, it solves the technical problem of low testing efficiency for base stations in related technologies, achieving the technical effect of improving the testing efficiency of base stations.

[0035] Optionally, in the embodiments of this application, the test equipment may be, but is not limited to, a computer system or test platform used to test the target base station.

[0036] In the embodiment provided in step S202, the reference base station information may be used, but is not limited to, to indicate the services supported by the target base station. The reference base station information may refer to, but is not limited to, technical parameters describing the service types and base station characteristics supported by the target base station. For example, the reference base station information may include, but is not limited to, the base station's equipment type, software version, station type identifier, scene label, etc.

[0037] Optionally, in this embodiment, the test items may be, but are not limited to, a complete set of tests in the test equipment used to verify the functions of a specific type of base station, and each test item may correspond to the service capabilities of a type of base station.

[0038] Optionally, in this embodiment, the test item library of the test device may, but is not limited to, store multiple test items executed by the test device, or may, but is not limited to, store test items supported by the test device, etc.

[0039] As an optional implementation, target test items matching the target base station can be selected from the various test items stored in the test item library of the test equipment based on the reference base station information of the target base station in the following manner: a project sub-library is constructed based on the test file set of the test equipment, wherein the project sub-library is used to store available test items that can be executed, the test file set stores the files used by the test equipment during the test execution process, and the test item library includes the project sub-library; target test items that can be used to test the target base station are selected from the available test items stored in the project sub-library based on the reference base station information.

[0040] Optionally, in this embodiment, the various test files / test data required by the test device may, but are not limited to, be stored in the test file collection of the test device in the form of files.

[0041] Optionally, in this embodiment, a project sub-library can be constructed first based on the test file set of the test device to store available test items that can be executed, and then the target test items can be filtered from the project sub-library to avoid selecting test files that cannot be executed.

[0042] As an optional implementation, a project sub-library can be constructed based on the test file set of the test equipment in the following ways, but not limited to: traversing the file directory of the test file set to find subdirectories with target identifiers, where the target identifier is used to identify test projects; extracting the files corresponding to the subdirectories to obtain candidate test projects; filtering out usable test projects from each candidate test project based on the directory information, composition information, and execution information of each candidate test project, where the directory information indicates the directory hierarchy of the subdirectory corresponding to the candidate test project in the file directory, the composition information indicates the test script file settings at the target location in the subdirectory corresponding to the candidate test project, and the execution information indicates whether the test script file includes executable test cases; storing the usable test projects to obtain the project sub-library.

[0043] Optionally, in this embodiment, a scan can be performed on the preset working directory of the test device (i.e., the file directory mentioned above) to generate a set of candidate test directories (i.e., the project sub-library mentioned above).

[0044] Optionally, in this embodiment, the preset working directory may be, but is not limited to, the root directory of the test device's storage space.

[0045] Optionally, in this embodiment, after the test device is started, the root directory can be used as a fixed scanning starting point to traverse the first-level subdirectories and add the subdirectories whose directory names begin with "testcase_" (i.e. the target identifier mentioned above) to the candidate test directory set to obtain candidate test items.

[0046] Optionally, in this embodiment, the directory information may refer to, but is not limited to, the positional and structural characteristics of the subdirectories corresponding to the candidate test items in the test file set. The directory information may be used, but is not limited to, primarily to determine whether the directory conforms to the organizational specifications that a test item should have.

[0047] Optionally, in this embodiment, the composition information may refer to, but is not limited to, the file structure characteristics within the candidate test project directory, especially the distribution and existence of test script files. The composition information may be used, but is not limited to, to determine whether the directory has the basic content for executing tests.

[0048] Optionally, in this embodiment, the execution information may be used, but is not limited to, to indicate whether the test script file itself has executable test cases. For example, the execution information may be used, but is not limited to, to indicate whether the test script file includes the "test cases" defined in Robot Framework. "Test Cases" semantic region.

[0049] Optionally, in this embodiment, a hierarchical weighted scoring method can be used to select available test items from each candidate test item based on the candidate test item's directory information, composition information, and execution information.

[0050] In some embodiments, after obtaining candidate test items, available test items can be selected in the following ways, but not limited to: calculating the project matching degree of each candidate test item based on directory structure features, file composition features, and execution availability features, and identifying directories with matching degrees reaching a preset project matching threshold as available test items. The directory structure features may include, but are not limited to, whether the candidate directory is located as a first-level subdirectory of the root directory and whether the directory name begins with "testcase_"; the file composition features may include, but are not limited to, whether the top level of the candidate directory contains one or more .robot files (i.e., the test script files mentioned above); and the execution availability features may include, but are not limited to, whether the .robot file can be read normally and subsequently parsed to obtain "testcase_". Test Cases "Use case names in the area."

[0051] In some embodiments, scores can be assigned to candidate test projects based on, but are not limited to, the distribution of .robot files, resource file references, the existence of variable files, the existence of execution scripts, and the existence of configuration files. Specifically, the distribution of .robot files may, but is not limited to, refer to the .robot files being located at the top level of the selected test project directory, rather than at any arbitrary deep recursive location; resource file references may, but are not limited to, references to Variables, Resource, or Library statements in the package file header; the existence of variable files may, but is not limited to, the existence of variable files such as config_common.py and config_common_femto.py referenced in the package; the existence of execution scripts may, but is not limited to, whether the selected package can be started by executing commands through Robot Framework; and the existence of configuration files may, but is not limited to, the existence of credentials configuration files in the storefile directory that can be loaded by the current project.

[0052] In some embodiments, the project matching degree can be, but is not limited to, equivalently represented by summing the values ​​assigned to the aforementioned rule items. For example, matching the directory name prefix is ​​recorded as the first sub-sub ...

[0053] In some embodiments, for the identified test items (i.e., available test items), semantic parsing may be performed on the .robot files therein, including but not limited to reading the test case definition section, task definition section, resource reference section and variable reference section, in order to distinguish between test suite files that can be executed independently and auxiliary files that are only used as public resource references. It may be further determined that .robot files that meet the independent execution conditions are available test suites.

[0054] As an optional implementation, usable test projects can be selected from each candidate test project based on the directory information, composition information, and execution information of each candidate test project in the following ways: checking whether the directory information of each candidate test project meets the directory condition, checking whether the composition information of each candidate test project meets the composition condition, and checking whether the execution information of each candidate test project meets the execution condition. The directory condition is that the subdirectory corresponding to the test project is at the first-level subdirectory position; the composition condition is that the root directory of the subdirectory corresponding to the test project includes at least one test script file; and the execution condition is that the test script files in the test project include executable test cases. If it is detected that the directory information of a candidate test project meets the directory condition, the composition information of a candidate test project meets the composition condition, and the execution information of a candidate test project meets the execution condition, then the candidate test project is determined as a usable test project.

[0055] Optionally, in this embodiment, the directory condition may, but is not limited to, refer to the requirement that the hierarchical structure of the subdirectories corresponding to the candidate test items in the test file set must conform to a preset specification. The core purpose is to ensure the uniformity and identifiability of the project organization, avoiding misidentification or duplicate loading due to path confusion. For example, the directory condition may, but is not limited to, require that the subdirectory must be located directly under the first-level subdirectory of the scan starting point.

[0056] Optionally, in this embodiment, the constituent conditions may, but are not limited to, requiring that the candidate test project directory must contain at least one valid test script file to indicate that the directory has substantive content for test execution, rather than merely serving as a configuration or documentation container. For example, the constituent conditions may, but are not limited to, require that one or more test script files with the ".robot" extension exist in the root directory of each candidate project directory.

[0057] Optionally, in this embodiment, the execution condition may, but is not limited to, require that at least one .robot test script file in the candidate test project must contain executable test case definitions. For example, the script may, but is not limited to, contain the definition of "robot test". Test Cases The title section should include the specific test case names listed below it.

[0058] Optionally, in this embodiment, a candidate test project may be determined as an available test project if, but is not limited to, the directory information, composition information, and execution information of the candidate test project meet the directory conditions, the composition information, and the execution information meet the execution conditions; or, but is not limited to, the candidate test project may be determined as an unavailable test project if, but is not limited to, the directory information, composition information, and execution information of the candidate test project do not meet the directory conditions, and / or, the composition information, and / or the execution information does not meet the execution conditions.

[0059] As an optional implementation, target test projects that support testing the target base station can be selected from the available test projects stored in the project sub-library based on the reference base station information in the following ways: reading each available test suite from the available test projects in the project sub-library; selecting candidate test suites that match the target base station from each available test suite based on the reference base station information and the operation information of each available test suite, thereby obtaining available test projects and candidate test suites with corresponding relationships, wherein the operation information is used to indicate the base station service tested by the available test suites; displaying the available test projects and candidate test suites with corresponding relationships, as well as the test cases included in each candidate test suite, on the user interface; in response to the selection of a reference test project in the available test projects, the selection of a reference test suite in the reference test projects, and the selection of reference test cases in the reference test suites, determining the test suite including the reference test cases as the target test suite, and determining the test project including the target test suite as the target test project.

[0060] Optionally, in this embodiment, after filtering out available test projects, it is possible, but not limited to, further determining the available test suites among the available test projects. For example, after building the project sub-library, it is possible, but not limited to, opening each available test project directory one by one, scanning all files with the .robot extension in their root directory, and using a syntax parser to identify whether these files contain " Test Cases "Semantic segment, if it exists, marks it as an available test suite, and records the project name, file path and internally defined test case list of the suite."

[0061] In some embodiments, but not limited to, metadata matching can be used to filter candidate test suites that match the target base station from among the available test suites based on reference base station information and the operational information of each available test suite, resulting in a corresponding list of available test items and candidate test suites. Specifically, each test suite declares its target base station type, version, or scenario parameters in its header or associated variable file. This metadata can be read at startup and compared with the reference base station information of the target base station. For example, if the "access_control.robot" file references "config_femto.py", which defines "DEVICE_TYPE = 'FEMTO'" and "SW_VERSION = 'V2.1.3'", and the target base station's reference base station information is "Device type: Femto, Software version: V2.1.3", then the test suite can be determined to be a complete match and added to the candidate set. Another test suite, "handover_macro.robot", references "config_macro.py", which defines "DEVICE_TYPE = The option 'MACRO' was excluded due to inconsistency in device type, resulting in the following correspondence between available test items and candidate test suites: 'testcase_femto—access_control.robot' and 'testcase_femto—power_adjust.robot'.

[0062] In some embodiments, but not limited to, the following methods can be used to filter out candidate test suites that match the target base station from each available test suite based on the reference base station information and the operation information of each available test suite, thereby obtaining available test items and candidate test suites with corresponding relationships: parsing the file header information of the reference test suite, extracting the tag set declared in the reference test suite, wherein the tag set includes base station type tags, service function tags, and version compatibility tags; converting the reference base station information into a standardized tag vector; calculating the matching degree between the tag set and the standardized tag vector; and determining the reference test suite with a matching degree greater than a preset threshold as a candidate test suite.

[0063] Optionally, in an embodiment, after obtaining the available test items and candidate test suites with corresponding relationships, the available test items and candidate test suites with corresponding relationships may be displayed on the user interface. Figure 3 This is a schematic diagram of a user interface according to an embodiment of this application. For example... Figure 3 As shown, available test items can be displayed in the project selection bar, but not limited to this: after the user selects an available test item, the available test suites corresponding to the user-selected available test item can be displayed in the suite selection bar.

[0064] In the embodiment provided in step S204, the target service information may refer to, but is not limited to, the specific parameters and operating logic that the target base station relies on when actually running a certain service. For example, when the target base station is to perform "load-based dynamic power control", its target service information may include, but is not limited to, "load trigger threshold is 75%", "power downsizing step size is 1.5dB", "adjustment response time must not exceed 4 seconds", "maximum transmit power limit is 26dBm", etc.

[0065] Optionally, in this embodiment, the target service information may, but is not limited to, be directly represented as parameters required for service execution, or may, but is not limited to, indirectly represented by the identifier of the target base station (e.g., base station model), etc. This application does not limit this.

[0066] Optionally, in this embodiment, the test item library of the test device may store, but is not limited to, multiple configuration files in addition to test items.

[0067] Optionally, in this embodiment, a test case may be, but is not limited to, the smallest, independently executable verification unit in the test suite.

[0068] Optionally, in this embodiment, the target configuration file may, but is not limited to, be used to indicate how multiple test cases included in the target test project should be executed. The execution mode of multiple test cases may, but is not limited to, refer to the set of environment parameters that the test cases depend on during execution.

[0069] Optionally, in this embodiment, the reason for selecting the configuration file after selecting the test project / kit is that in complex testing scenarios, a test kit often needs to adapt to multiple device models, software versions, and service scenarios. If the parameters are hardcoded into the kit, a kit can only be used for one configuration. Once the base station version is upgraded or the scenario is switched, the entire kit must be copied and modified, resulting in code redundancy, maintenance difficulties, and version confusion. For example, the "power_control.robot" kit in the "testcase_femto" project may need to support three versions simultaneously: V2.1, V2.2, and V2.3. Each version has different power control parameters. If the configuration is embedded in the kit, three identical files must be maintained, differing only in parameters. This is not only extremely inefficient but also prone to errors. By separating the configuration file, the corresponding credentials_femto_v21.ini and credentials_femto_v22.ini can be automatically loaded at runtime based on the reference information of the target base station, achieving flexible adaptation of "one set of test logic, multiple sets of running parameters".

[0070] As an optional implementation, the following methods can be used, but are not limited to, to find the target configuration file of the target test project that matches the target base station from the various configuration files stored in the test project library based on the target service information of the target base station: obtaining the default configuration file of the target test project, wherein the default configuration file includes configuration parameters with corresponding relationships and a first configuration value; updating the configuration values ​​of the configuration parameters in the default configuration file with the second configuration values ​​of each configuration parameter obtained from the external configuration file to obtain an intermediate configuration file, wherein the external configuration file is the configuration file used by the test target base station specified by the user; updating the configuration values ​​of the configuration parameters in the intermediate configuration file with the third configuration values ​​of each configuration parameter obtained from the user interface to obtain a candidate configuration file; detecting the matching parameters between the candidate configuration file and the target service information, wherein the matching parameters are used to indicate the degree of matching between the candidate configuration file and the target service information; and determining the candidate configuration file as the target configuration file if the matching parameters are greater than the matching parameter threshold.

[0071] Optionally, in this embodiment, a configuration file that is highly matched to the service requirements of the target base station can be generated by overlaying multiple configuration sources, but is not limited to.

[0072] Optionally, in this embodiment, the default configuration file may be, but is not limited to, a set of baseline configurations built into each test project. The default configuration file may be, but is not limited to, preset by the test team for a specific type of base station during the development phase, representing the most commonly used parameter combinations for this type of device in standard scenarios.

[0073] Optionally, in this embodiment, after determining the target test project, a fixed mapping can be performed based on the project name of the target test project to obtain the default configuration file of the target test project. For example, when the project is testcase_femto, credentials_femto.ini under the storefile directory is loaded, and when the project is testcase_m4371, credentials_m4371.ini is loaded.

[0074] Optionally, in this embodiment, for some test items, a specified default configuration file may not be set. In this case, a default configuration file common to the target base station may be loaded, but is not limited to. For example, for the remaining items other than the aforementioned testcase_femto and testcase_m4371, credentials_common.ini may be loaded, but is not limited to.

[0075] Optionally, in this embodiment, the default configuration file may include, but is not limited to, corresponding configuration parameters and a first configuration value. It may, but is not limited to, reading the section (i.e., the aforementioned configuration parameters) and key (i.e., the aforementioned first configuration value) from the .ini file after loading the .ini file.

[0076] Optionally, in this embodiment, after reading the .ini file, input boxes corresponding to each section can be generated in the global parameter area of ​​the user interface for the user to input a third configuration value.

[0077] Optionally, in this embodiment, the external configuration file may be, but is not limited to, a supplementary or corrective file that is actively specified by the user or operations personnel for a specific test task, overriding the default configuration. The external configuration file may be, but is not limited to, loaded through file upload, path binding, or configuration management platform. For example, it may be possible, but is not limited to, determining whether there is an external file path corresponding to the target test project in credentials_binding.ini. If it is determined that there is an external file path corresponding to the target test project, it may be possible, but is not limited to, reading the external ini file and overwriting the key value of the section with the same name in the default configuration file.

[0078] Optionally, in this embodiment, the third configuration value of the configuration parameter obtained by the user interface may be, but is not limited to, a temporary input value that the tester modifies in real time in the graphical interface and has not yet been saved.

[0079] Optionally, in this embodiment, for configuration parameter values, temporary input values ​​from the user interface may have the highest priority, followed by external configuration files, and finally the default configuration file. That is, when a configuration parameter exists at all three levels, the value modified by the interface will override the value in the external file, and the value in the external file will override the default value, forming a hierarchical override chain. This priority design ensures the controllability and security of testing. Default values ​​ensure basic stability, external files provide a traceable and reusable environmental baseline, and interface input gives testers the highest control at critical moments, allowing them to quickly verify hypotheses or respond to emergencies without modifying any files, without needing to edit or upload new files, greatly improving debugging efficiency.

[0080] As an optional implementation, the matching parameters between the candidate configuration file and the target service information can be detected in the following ways, but are not limited to: extracting a set of configuration parameters from the candidate configuration file, wherein the set of configuration parameters includes at least the base station model parameters, base station software version parameters, base station management address parameters, and base station test scenario parameters supported by the candidate configuration file. The base station management address parameters are used to connect to the base station, and the base station test scenario parameters are used to indicate the test environment conditions that need to be met during the testing of the base station; detecting the degree of matching between the configuration values ​​of each configuration parameter included in the set of configuration parameters and the parameter values ​​of each operating parameter included in the set of operating parameters of the target base station, and obtaining each intermediate matching value, wherein the target service information includes a set of operating parameters, which includes at least the base station model parameters, base station software version parameters, base station management address parameters, and base station operating scenario parameters of the target base station. The base station operating scenario parameters are used to indicate the current operating environment of the target base station; and determining the matching parameters based on each intermediate matching value.

[0081] Optionally, in this embodiment, it is possible, but not limited to, to determine whether the configuration is truly suitable for the current test target by quantitatively comparing the consistency between the environmental configuration parameters in the candidate configuration file and the actual operating parameters of the target base station.

[0082] Optionally, in this embodiment, the set of configuration parameters may include, but is not limited to, base station model parameters, base station software version parameters, base station management address parameters, and base station test scenario parameters. These parameters may, but are not limited to, collectively define the underlying environmental conditions on which the test execution depends.

[0083] Optionally, in this embodiment, the base station model parameter may be used, but is not limited to, to identify whether the test object is a Femto small station, a Macro large station, or other station type, ensuring that the test suite matches the hardware type; the base station software version parameter may be used, but is not limited to, to confirm whether the current test is for a specific version such as V2.1.3 or V3.0.0, avoiding running test cases on incompatible versions; the base station management address parameter may be, but is not limited to, the IP address or port number used to establish a communication connection with the target base station. If the configuration specifies 192.168.1.10, but the actual base station is located at 192.168.1.20, the test will fail to establish a connection; the base station test scenario parameter may be, but is not limited to, describing the environmental conditions required for the test, such as "high-density users," "low mobility," "indoor coverage," etc. The base station test scenario parameter may be, but is not limited to, determining whether it is necessary to simulate specific terminal behavior or network load during the test.

[0084] Optionally, in this embodiment, the degree of matching between the configuration value of each configuration parameter and the parameter value of each running parameter can be detected by an exact matching method, that is, the configuration value of the configuration parameter can be compared with the parameter value of the running parameter corresponding to the configuration parameter one by one, and the intermediate matching value can be determined by measuring the degree of consistency between the two.

[0085] Optionally, in this embodiment, the degree of matching between the configuration values ​​of each configuration parameter and the parameter values ​​of each operating parameter can be detected by fuzzy matching based on semantic similarity, but not limited to this. For example, when the base station test scenario parameter in the candidate configuration file is "low power coverage" and the base station operating scenario parameter is "energy saving mode", the semantic equivalence of the two can be identified by the built-in business scenario thesaurus, and a perfect intermediate matching value can be given, etc.

[0086] Optionally, in this embodiment, a weighted average method can be used to combine various intermediate matching values ​​to determine the matching parameter: each intermediate matching value can be assigned a different weight according to the criticality of the configuration / running parameters corresponding to the intermediate matching value in the test environment. For example, model and version have high weight, address has secondary weight, and scenario has the lowest weight. Then, a weighted sum is performed to obtain a matching parameter between 0 and 1. If the sum is higher than 0.85, it is determined to be highly compatible.

[0087] In the embodiment provided in step S206, the target base station can be tested according to the target configuration file and the target test items after the target configuration file and the target test items have been determined.

[0088] Optionally, in this embodiment, after determining the target configuration file and the target test item, the execution strategy of the target test item can be determined, but is not limited to. For example... Figure 3As shown, the execution strategy can be determined in the execution control bar, but is not limited to this.

[0089] Optionally, in this embodiment, a structured task object may be generated after the test items, test suites, test cases, and execution strategies have been determined. A configuration snapshot uniquely corresponding to the task may be generated before the task object is enqueued for execution; this configuration snapshot may be, but is not limited to, an independent configuration file, a structured serialized object, or a memory-mapped structure. The environment required for the task object's runtime may be solidified at the task level through the creation of the task object and the configuration snapshot, enabling the task to form an execution unit that can be independently scheduled, paused, resumed, retried, and traced after being enqueued.

[0090] Optionally, in this embodiment, the execution of task objects can be scheduled based on, but is not limited to, the overall operation / testing status of the target base station. This can be done by reading task objects from the current running queue, extracting their resource requirement sets, and constructing a current resource occupancy graph; for each task object to be scheduled, checking whether its planned trigger time has arrived (for timed tasks); checking whether the number of currently running tasks is less than the maximum concurrency; performing conflict detection on the resource requirement set of the task and the current resource occupancy graph: if any resource of the task to be scheduled overlaps with any resource of any running task, a resource conflict is determined; constructing a task conflict graph and marking conflicting task pairs as mutually exclusive edges; if a task meets the trigger time condition, does not exceed the concurrency limit, and has no resource conflict, it is moved from the waiting queue to the executable queue; if there is a resource conflict but the concurrency limit has not been exceeded, it is moved to the resource waiting queue to wait for the conflicting resources to be released; if the timed trigger time has not arrived, it remains in the waiting queue and the next scheduling time window is updated; tasks with the same test batch identifier are prioritized for scheduling to ensure environmental consistency within the batch.

[0091] Optionally, in this embodiment, the execution process of the task object can be monitored, but is not limited to monitoring the resource usage status of the base station and the generation status of monitoring logs during the execution of the task object.

[0092] Optionally, in this embodiment, the execution result file (e.g., output.xml result file) of the task object can be extracted after the task object is executed, but is not limited to this. The various output.xml result files can be filtered and merged, for example, files that passed the test can be grouped into one category and merged, while files that failed the test can be grouped into another category and merged, etc.

[0093] As an optional implementation, this application also provides an automated base station testing system. This system can, but is not limited to, display test operations through a graphical interface. Instead, it achieves seamless integration of test tasks from definition, queuing, execution to result output through underlying mechanisms such as automatic test asset discovery, test case semantic parsing, configuration snapshot persistence, constrained task object modeling, resource conflict-aware scheduling, independent execution context control, event-driven state monitoring, and batch-level result merging analysis.

[0094] Optionally, the aforementioned system may include, but is not limited to, at least a test asset management module, a test case parsing and selection module, a configuration management module, a task modeling module, a task scheduling module, an execution control module, a status monitoring module, and a result integration and report generation module.

[0095] Figure 4 This is a schematic diagram of an automated base station testing system according to an embodiment of this application. Figure 5 This is a flowchart of a base station testing method according to an embodiment of this application. Figure 2 .like Figure 4 As shown, the test asset management module can, but is not limited to, scan a preset working directory (i.e., the aforementioned file directory) to generate a candidate test directory set (i.e., the aforementioned project sub-library). In a graphical interface implementation, the preset working directory is the root directory of the project where the graphical interface main program (i.e., the aforementioned test device) is located. After the interface starts, the project root directory is used as a fixed scanning starting point, and its first-level subdirectories are traversed. Subdirectories whose names begin with "testcase_" are added to the candidate test directory set. The preset working directory belongs to the existing file organization and interface scanning mechanism. The project selection drop-down list is automatically generated based on the above scanning results. After the user selects a candidate test directory, the top-level .robot files under that directory are enumerated to form a suite selection drop-down list.

[0096] Based on the above features, the item matching degree of the candidate directories is calculated, and directories with a matching degree reaching a preset threshold are identified as test items. In a graphical interface implementation, the item matching degree can be calculated using, but is not limited to, a rule-based determination method.

[0097] Optionally, in this embodiment, the environment configuration file, version identifier file, and execution script file associated with the test project can be read, but are not limited to, to extract the target device type, version number, scene tag, and environment parameters, and establish an association relationship of "test project - test suite - execution environment" accordingly. Only test suites compatible with the current target environment are added to the executable suite set (i.e., the available test suites mentioned above). To avoid duplicate display caused by directory copying, version branching, or path mapping, path normalization and suite fingerprint generation are performed on the candidate test suites (i.e., the available test suites mentioned above). The suite fingerprint is generated based at least on the file content summary, suite name, dependent resource information, and the project identifier. Suites with the same fingerprint or similarity exceeding a threshold are merged or classified by version.

[0098] Furthermore, during the initial load, a test asset index table can be established, and during operation, events such as file addition, deletion, renaming, and configuration modification in the working directory can be monitored. When a change event is detected, only the affected directory is partially re-parsed to incrementally update the test project index, test suite index, and environment association information, thereby achieving real-time and complete display of test projects and test suites.

[0099] Optionally, in this embodiment, the test case parsing and selection module may include, but is not limited to, a test case semantic parsing unit, which is used to perform syntax-level and semantic-level parsing on the corresponding .robot file after the user selects a test suite, and to identify test case definition boundaries, test case names, tag information, parameterized instance information, resource dependencies and execution condition information.

[0100] Optionally, in this embodiment, the system may, but is not limited to, extracting test names solely through string matching. Instead, it may construct a test case index structure within the test suite, mapping each test case to its suite, tag set, parameterized identifier, dependent resources, and executable conditions. For entries that are merely templates, resource references, or lack independent executable conditions, the system removes them from the optional test case set or marks them as non-executable entries.

[0101] Optionally, in this embodiment, the system may, but is not limited to, generate a visual selection set based on the test case index structure, and support filtering, grouping, and batch selection of test cases by tags, scenario types, functional modules, priorities, or historical execution results; when the user selects all, deselects, or partially selects, the system actually modifies the selection identifier in the test case index, rather than directly relying on the state of the interface controls, thereby ensuring that the selected test case set can be directly solidified into task object input by the task modeling module.

[0102] Optionally, in this embodiment, the configuration management module may include, but is not limited to, a project-associated configuration loading unit. The project-associated configuration loading unit is used to load the configuration file corresponding to the project based on the project selection result in the graphical interface after identifying the test project.

[0103] Optionally, in this embodiment, if ui_state.ini exists in the test project library, the system can also restore the previously saved project and suite selection state.

[0104] Optionally, in this embodiment, the system may, but is not limited to, determine a set of candidate configuration files in the storefile directory and external binding paths based on configuration reference clues (mainly including the current project name, the mapping relationship between the project and the credentials configuration file, the external configuration path recorded in credentials_binding.ini, and the same-name overriding relationship between sections and keys). For each candidate configuration file, the system extracts its association features, which may, but are not limited to, include at least the project name mapping relationship, configuration file path, section name, key name, and whether it comes from an external binding file; and matches the association features with the current project selection result to determine the configuration association relationship. In a graphical interface implementation, the configuration association relationship may, but is not limited to, be determined by rule matching. The system may, but is not limited to, assemble the configuration files in the project configuration set in layers according to the project default credential layer, the external binding overriding layer, and the interface temporary editing layer, and parse the same-name parameters in sequence according to a preset priority. The system consists of three layers: the default credential layer (referred to as the default configuration file), the external binding overriding layer (referred to as the external INI file bound to the current project in credentials_binding.ini), and the temporary interface editing layer (referred to as the third configuration value). The system can be configured as follows: first, it reads the default credential layer and generates basic parameter items in the interface according to the section and key; second, it reads the external binding overriding layer and overwrites the values ​​of sections and keys with the same name; finally, it uses the value in the current input box as the final display value and writes it back to the corresponding credentials configuration file when the user clicks "Save". For parameters overridden by later layers, the system can trace their source based on the local file path, external binding path, and section and key names of the current project. The graphical form displays the parsed final effective parameters and their source information, not just the original configuration file content.

[0105] Optionally, in this embodiment, the system may, but is not limited to, extract base station model, software version, station type identifier, test scenario and target address parameters from candidate configuration files based on the currently selected test item, test suite and target base station environment, and only load configuration files that match the current execution environment (i.e. the target configuration files mentioned above); for mismatched configuration files, the system marks them as unexecutable associated configurations or downgrades them to backup configurations to avoid test execution abnormalities caused by misloading.

[0106] Optionally, in this embodiment, during the actual execution of the test task, the system records the configuration files called and the parameter coverage relationship; when it is detected that a candidate configuration file is not actually referenced, or that there are missing parameters, field conflicts, or environment mismatches, the system automatically corrects the association weight of the configuration file, and prioritizes the use of historically verified configuration combinations in subsequent loading of similar projects, thereby improving the accuracy and stability of automatic configuration association.

[0107] Optionally, in this embodiment, such as Figure 5 As shown, the task modeling module can, but is not limited to, generate a structured task object (i.e., a configuration task) after the user selects a test project, test suite, target test case, and execution strategy. This object will include at least the following: task identifier, test batch identifier, project identifier, suite identifier, suite path, test case set, configuration snapshot identifier, target base station identifier, version tag, scenario tag, resource requirement set, conflicting resource set, execution priority, planned trigger time, earliest execution time, latest completion time, preceding task identifier, retry strategy identifier, and result output path.

[0108] Optionally, in this embodiment, the system may, but is not limited to, set up a multi-level task queue, including a waiting queue, an executable queue, a running queue, and a completed queue. Newly generated test task objects first enter the waiting queue. After the scheduler performs execution slot analysis, configuration loading check, and timed trigger condition judgment on the task objects, they are transferred to the executable queue or remain in the waiting queue. Among them, the execution slot analysis is used to read the maximum concurrency parameter and the number of tasks currently running in the interface to determine whether there are any free execution slots; the configuration loading check is used to confirm that the current project and suite have been selected, the suite file path exists, and the credentials configuration file corresponding to the current project has been loaded into the "global parameters" area; the timed trigger condition judgment is used to determine whether the predetermined trigger time has been reached, whether the selected day of the week in the weekly mode is met, and whether the time interval and remaining number of times in the interval mode are met for modes such as immediate execution, single execution, daily repetition, weekly repetition, and time interval repetition. In one graphical interface implementation, each task occupies a test execution process slot and a result output directory by default. When there is an idle execution slot and the timed trigger condition is met, the task changes from the queued state to the running state; otherwise, it continues to remain in the queue waiting.

[0109] It is important to note that the system does not control task execution solely based on the maximum concurrency. Instead, it establishes a test resource reservation pool and a task conflict graph. The test resource reservation pool records the current occupancy status, available time windows, and release conditions of base station equipment resources, radio frequency resources, terminal simulation resources, log collection resources, network interface resources, and external control resources. The task conflict graph represents the resource mutual exclusion relationships and scenario mutual exclusion relationships between different test tasks.

[0110] Optionally, in this embodiment, when the scheduler in the task scheduling module selects candidate tasks from the queue to be scheduled, it first reads the resource requirement set of the candidate tasks and performs conflict detection with the resource requirement sets of each task in the current running queue. Only when there is no conflict edge between the candidate task and the running task, and the required resources are successfully reserved in the test resource reservation pool, will the scheduler allocate the task to an idle execution unit for execution. For tasks that, although not exceeding the maximum concurrency, have shared exclusive resources, the same target base station, or mutually exclusive test scenarios, the scheduler prevents them from running concurrently and transfers them to the resource waiting queue, thereby realizing conflict-aware parallel scheduling for base station test scenarios.

[0111] Optionally, in this embodiment, the system may, but is not limited to, assign a unified test batch identifier to tasks with the same target base station, the same version tag, and the same scenario configuration; the scheduler prioritizes ensuring that tasks within the same test batch are executed continuously within the validity period of the same environment snapshot. When a target base station restart, version switch, scenario parameter change, or abnormal resource release is detected, the system re-marks the unexecuted tasks in the test batch as pending environment recovery to ensure the consistency and comparability of test results within the batch.

[0112] Optionally, in this embodiment, the execution control module creates independent execution contexts for test tasks entering the run queue. An independent execution context includes at least a task-level working directory, a task-level configuration snapshot mapping, a task-level log output channel, a task-level result output directory, and a task-level process control handle. The execution control module constructs test execution commands based on the suite path, test case set, and configuration snapshot identifier in the task object, and calls the Robot Framework execution engine to start the corresponding test task. During execution, the execution control module continuously maintains the task state machine, and the task state includes at least: queued, preparing, running, waiting for resources, paused, resuming, completed, failed, stopped, and abnormally terminated. The execution control module implements task start, pause, resume, stop, timeout interruption, and abnormal recovery control based on the task state machine; when a task exits abnormally, the system records the reason for the abnormal exit, the set of completed test cases, and environment state information, and transfers the task to the abnormal recovery queue or result archiving process.

[0113] Optionally, in this embodiment, the system includes a time window configuration unit and a condition-triggered scheduling unit. Users can set one-time, periodic, or intermittent trigger rules for scheduled tasks, and further set the allowed execution time window, repetition period, and deadline conditions. The system simultaneously maintains the availability status of the scheduler's execution slots and the next execution time window for each scheduled task. In a graphical interface implementation, the so-called unavailability of test resources for a certain period mainly refers to the fact that the number of tasks currently running has reached the maximum concurrency limit, causing new test execution slots to be temporarily unavailable. This unavailability status essentially means that other tasks have occupied currently available execution slots. Furthermore, for scheduled tasks that have not yet reached their predetermined trigger time, the system also considers them to be within a waiting time window. When the task trigger time arrives, the scheduler does not execute immediately, but first determines whether the task's predetermined trigger time has arrived and whether the number of currently running tasks is less than the maximum concurrency value. If the conditions are met, the task is added to the executable queue or directly started for execution.

[0114] When the time window, resource window, and environmental conditions are all met simultaneously, the scheduler automatically adds the scheduled task to the executable queue. When only the trigger time is met but the resource window or environmental conditions are not met, the system places the task in a delayed scheduling state and recalculates the scheduling time based on the resource release time, environmental recovery time, or the next candidate time window. For scheduled tasks with prerequisite dependencies, the system only submits the subsequent task to the executable queue when the prerequisite task executes successfully and the output meets the preset conditions, thus forming a conditional chained scheduling mechanism for base station testing processes.

[0115] Optionally, in this embodiment, the status monitoring module may, but is not limited to, use an event-driven mechanism to uniformly collect and distribute task status, log output, resource usage changes, and statistical indicator changes during execution. For log events, log streams from multiple concurrent tasks are split, marked, and reassembled according to task identifiers to form task-level log streams and batch-level log streams; for status change events, the system updates the current task status, queue, execution progress, and exception identifier according to the task state machine; for resource events, the system updates the number of running tasks, queued tasks, resource usage, and the next candidate scheduling time in real time; for result events, the system dynamically updates statistical indicators such as total number of tests, number of passes, number of failures, number of skips, number of exceptions, and pass rate.

[0116] Optionally, in this embodiment, after each test task is completed, the result extraction unit in the result integration and report generation module automatically locates the corresponding output.xml result file based on the task identifier, constructs a hierarchical result tree, and identifies valid test case nodes from it. The system extracts the test case identifier, execution status, start and end time, exception information, retry flag, source task identifier, test batch identifier, target base station identifier, version tag, scene tag, and environment snapshot identifier for each test case node. For duplicate result nodes generated by repeated execution, abnormal recovery execution, or breakpoint resumption, the system performs normalization processing, retains the final valid result nodes, and counts the number of passes, failures, skips, and exceptions respectively, generating single-task-level structured result data. After receiving the structured result data of multiple test tasks, the batch merging and analysis unit in the result integration and report generation module does not directly perform splicing merging on all output.xml files, but first establishes a result merging set based on the test batch identifier, target base station identifier, version tag, scene tag, and environment snapshot identifier; only test results that meet the conditions of environmental consistency and result comparability are divided into the same merging set. For test results that are inconsistent in environment, version, scenario, or fail the result integrity verification, the system transfers them to an isolated set or an exception archive set to avoid incorrect merging of results from different contexts.

[0117] Furthermore, the batch merging and analysis unit extracts failure feature vectors from the failed and abnormal results in the merge set. These failure feature vectors include at least the failure keyword path, error message characteristics, exception code, associated functional module, target base station version, test scenario parameters, resource occupancy status, and failure occurrence sequence. The system calculates the similarity between different failure results based on these feature vectors and groups failure results with similarity exceeding a threshold into the same abnormal cluster. For each abnormal cluster, the system extracts its common failure features and generates cluster-level analysis conclusions to identify whether batch failures are caused by the same root cause, the same version defect, the same environmental anomaly, or the same resource conflict.

[0118] After completing result grouping, normalization, and anomaly clustering analysis, the report generation unit in the results integration and report generation module calls the rebot tool to merge the result files in the same merge set. Based on the rebot merged results, batch-level statistics, environment snapshot information, anomaly cluster index information, duplicate failure merge identifiers, and task chain information are added to generate a comprehensive test report. The comprehensive test report includes not only log.html and report.html, but also structured index data for the test batch, used to display batch pass rate, failure mode distribution, number of anomaly clusters, attribution of major problems, and correlations between results from different tasks.

[0119] After the report is generated, an index mapping relationship of "batch report - task report - anomaly cluster analysis results" can be established, but is not limited to, and corresponding quick access entry points can be provided in the graphical interface. Users can view the comprehensive report, single task report and anomaly cluster analysis results through the entry points, thereby realizing hierarchical analysis from batch overview to single task details and failure mode attribution.

[0120] Figure 6 This is an architecture diagram of a base station testing method according to an embodiment of this application. Figure 6 As shown, the base station testing method provided in this application may include, but is not limited to, a three-layer architecture: the user interaction and configuration layer is responsible for all front-end inputs; the control and scheduling layer is the central nervous system of the aforementioned system, handling all logic and scheduling; and the test execution and data layer is the limbs of the aforementioned system, responsible for the implementation of specific test tasks. Each of the aforementioned three layers interacts with the data persistence and reporting layer to complete data storage and the output of the final report.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software and necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0122] Figure 7 This is a structural block diagram of a base station testing apparatus according to an embodiment of this application. This apparatus can be, but is not limited to, testing equipment applied to a target base station; such as... Figure 7 As shown, the device may include, but is not limited to:

[0123] The filtering module 702 is used to filter out target test items that match the target base station from the various test items stored in the test item library of the test equipment according to the reference base station information of the target base station. The reference base station information is used to indicate the services supported by the target base station, and different test items are used to test base stations that support different services.

[0124] The lookup module 704 is used to search for the target configuration file of the target test project that matches the target base station from the various configuration files stored in the test project library based on the target service information of the target base station. The target service information is used to characterize the way the target base station handles the supported services, and the target configuration file is used to characterize the running mode of multiple test cases included in the target test project. Each test case is used to perform service testing on a service function of the base station.

[0125] Test module 706 is used to test the target base station according to the target configuration file and target test items.

[0126] Through the above embodiments, the test equipment for the target base station selects target test items matching the target base station from various test items stored in the test item library based on reference base station information indicating the services supported by the target base station. Based on target service information characterizing the handling methods of the supported services by the target base station, it searches for target configuration files matching the target test items from various configuration files stored in the test item library. The target configuration file characterizes the operation mode of multiple test cases included in the target test item. Testing the target base station based on the target configuration file and the target test item achieves automated matching of the base station's test files and configuration files, avoiding mismatches between the base station and the test files or configuration files. Therefore, it solves the technical problem of low testing efficiency for base stations in related technologies, achieving the technical effect of improving the testing efficiency of base stations.

[0127] In some embodiments, the filtering module may include, but is not limited to: a building unit, configured to build a project sub-library based on the test file set of the test device, wherein the project sub-library is used to store available test projects that can be executed, the test file set stores the files used by the test device during the test execution process, and the test project library includes the project sub-library; and a filtering unit, configured to filter out target test projects that can be used to test the target base station from the available test projects stored in the project sub-library based on the reference base station information.

[0128] In some embodiments, the construction unit may, but is not limited to, also be used for: traversing the file directory of the test file set, finding subdirectories with target identifiers, wherein the target identifier is used to identify test projects; extracting the files corresponding to the subdirectories to obtain candidate test projects; filtering available test projects from each candidate test project based on the directory information, composition information, and execution information of each candidate test project, wherein the directory information is used to indicate the directory hierarchy position of the subdirectory corresponding to the candidate test project in the file directory, the composition information is used to indicate the test script file settings at the target position in the subdirectory corresponding to the candidate test project, and the execution information is used to indicate whether the test script file includes executable test cases; and storing the available test projects to obtain a project sub-library.

[0129] In some embodiments, the construction unit may, but is not limited to, further be used to: detect whether the directory information of each candidate test project meets the directory conditions, detect whether the composition information of each candidate test project meets the composition conditions, and detect whether the execution information of each candidate test project meets the execution conditions, wherein the directory condition is that the directory level of the subdirectory corresponding to the test project is a first-level subdirectory, the composition condition is that the root directory of the subdirectory corresponding to the test project includes at least one test script file, and the execution condition is that the test script file in the test project includes executable test cases; if it is detected that the directory information of the candidate test project meets the directory conditions, the composition information of the candidate test project meets the composition conditions, and the execution information of the candidate test project meets the execution conditions, the candidate test project is determined as an available test project.

[0130] In some embodiments, the filtering unit may, but is not limited to, further being used to: read each available test suite from the available test projects in the project sub-library; filter out candidate test suites that match the target base station from each available test suite according to the reference base station information and the operation information of each available test suite, to obtain available test projects and candidate test suites with corresponding relationships, wherein the operation information is used to indicate the base station service tested by the available test suites; display the available test projects and candidate test suites with corresponding relationships, as well as the test cases included in each candidate test suite, on the user interface; and in response to the selection of a reference test project in the available test projects, the selection of a reference test suite in the reference test projects, and the selection of a reference test case in the reference test suite, determine the test suite including the reference test case as the target test suite, and determine the test project including the target test suite as the target test project.

[0131] In some embodiments, the search module may include, but is not limited to: an acquisition unit, configured to acquire a default configuration file of the target test project, wherein the default configuration file includes configuration parameters and a first configuration value with corresponding relationships; a first update unit, configured to update the configuration values ​​of the configuration parameters in the default configuration file using the second configuration values ​​of each configuration parameter acquired from an external configuration file to obtain an intermediate configuration file, wherein the external configuration file is a configuration file used by the test target base station specified by the user; a second update unit, configured to update the configuration values ​​of the configuration parameters in the intermediate configuration file using the third configuration values ​​of each configuration parameter acquired from the user interface to obtain a candidate configuration file; a detection unit, configured to detect the matching parameters between the candidate configuration file and the target service information, wherein the matching parameters are used to indicate the degree of matching between the candidate configuration file and the target service information; and a determination unit, configured to determine the candidate configuration file as the target configuration file if the matching parameters are greater than a matching parameter threshold.

[0132] In some embodiments, the detection unit may, but is not limited to, further be used to: extract a set of configuration parameters from a candidate configuration file, wherein the set of configuration parameters includes at least the base station model parameters, base station software version parameters, base station management address parameters, and base station test scenario parameters supported by the candidate configuration file for testing, the base station management address parameters being used to connect to the base station, and the base station test scenario parameters being used to indicate the test environment conditions that need to be met during the testing of the base station; detect the degree of matching between the configuration values ​​of each configuration parameter included in the set of configuration parameters and the parameter values ​​of each operating parameter included in the set of operating parameters of the target base station, and obtain each intermediate matching value, wherein the target service information includes the set of operating parameters, the set of operating parameters including at least the base station model parameters, base station software version parameters, base station management address parameters, and base station operating scenario parameters of the target base station, the base station operating scenario parameters being used to indicate the current operating environment of the target base station; and determine matching parameters based on each intermediate matching value.

[0133] Embodiments of this application also provide a storage medium including a stored program, wherein the program executes the testing method of any of the aforementioned base stations when it is run.

[0134] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0135] Embodiments of this application also provide an electronic device including a memory and a processor, the memory storing a computer program, the processor being configured to run the computer program to perform the steps in any of the above-described base station testing method embodiments.

[0136] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0137] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0138] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described base station testing method embodiments.

[0139] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described base station testing method embodiments.

[0140] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0141] The above description is only an optional implementation of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for testing a base station, characterized in that, The testing equipment applied to the target base station, the method comprising: Based on the reference base station information of the target base station, target test items matching the target base station are selected from the various test items stored in the test item library of the test equipment. The reference base station information is used to indicate the services supported by the target base station, and different test items are used to test base stations that support different services. Based on the target service information of the target base station, the target configuration file of the target test project that matches the target base station is found from the various configuration files stored in the test project library. The target service information is used to characterize the handling method of the supported services of the target base station, and the target configuration file is used to characterize the operation mode of multiple test cases included in the target test project. Each test case is used to perform business testing on a service function of the base station. The target base station is tested according to the target configuration file and the target test items.

2. The method according to claim 1, characterized in that, The step of selecting target test items matching the target base station from the test item library stored in the test equipment based on the reference base station information of the target base station includes: A project sub-library is constructed based on the test file set of the test equipment, wherein the project sub-library is used to store available test projects that can be executed, the test file set stores the files used by the test equipment during the test execution process, and the test project library includes the project sub-library; Based on the reference base station information, the target test project that supports testing the target base station is selected from the available test projects stored in the project sub-library.

3. The method according to claim 2, characterized in that, The step of constructing a project sub-library based on the test file set of the test equipment includes: Traverse the file directory of the test file set and find the subdirectory with the target identifier, wherein the target identifier is used to identify the test project; Extract the files corresponding to the subdirectories to obtain candidate test items; The available test projects are selected from each of the candidate test projects based on the directory information, composition information and execution information of each candidate test project. The directory information is used to indicate the directory level position of the subdirectory corresponding to the candidate test project in the file directory. The composition information is used to indicate the test script file settings at the target location in the subdirectory corresponding to the candidate test project. The execution information is used to indicate whether the test script file includes executable test cases. Store the available test items to obtain the project sub-library.

4. The method according to claim 3, characterized in that, The step of selecting available test items from each of the candidate test items based on their directory information, composition information, and execution information includes: The method involves detecting whether the directory information of each candidate test project meets the directory conditions, detecting whether the composition information of each candidate test project meets the composition conditions, and detecting whether the execution information of each candidate test project meets the execution conditions. The directory conditions are that the directory level of the subdirectory corresponding to the test project is a first-level subdirectory, the composition conditions are that the root directory of the subdirectory corresponding to the test project includes at least one test script file, and the execution conditions are that the test script file in the test project includes executable test cases. If the directory information of the candidate test project among the candidate test projects meets the directory condition, the composition information of the candidate test project meets the composition condition, and the execution information of the candidate test project meets the execution condition, then the candidate test project is determined as the available test project.

5. The method according to claim 2, characterized in that, The step of selecting the target test project that supports testing the target base station from the available test projects stored in the project sub-library based on the reference base station information includes: Read each available test suite from the available test projects in the project sub-library; Based on the reference base station information and the operation information of each available test suite, candidate test suites matching the target base station are selected from each available test suite to obtain the available test items and candidate test suites with corresponding relationships. The operation information is used to indicate the base station service tested by the available test suite. The user interface displays the available test items and the candidate test suites with corresponding relationships, as well as the test cases included in each candidate test suite; In response to the selection of a reference test item among the available test items, the selection of a reference test suite among the reference test items, and the selection of a reference test case among the reference test suite, a test suite including the reference test cases is determined as a target test suite, and a test item including the target test suite is determined as the target test item.

6. The method according to claim 1, characterized in that, The step of searching for the target configuration file of the target test project that matches the target base station from the various configuration files stored in the test project library based on the target service information of the target base station includes: Obtain the default configuration file of the target test project, wherein the default configuration file includes configuration parameters and a first configuration value with corresponding relationships; The configuration values ​​of the configuration parameters in the default configuration file are updated using the second configuration values ​​of each configuration parameter obtained from the external configuration file to obtain an intermediate configuration file, wherein the external configuration file is a configuration file specified by the user for testing the target base station; The configuration values ​​of the configuration parameters in the intermediate configuration file are updated using the third configuration values ​​of each configuration parameter obtained from the user interface to obtain a candidate configuration file; The matching parameters between the candidate configuration file and the target business information are detected, wherein the matching parameters are used to indicate the degree of matching between the candidate configuration file and the target business information; If the matching parameter is greater than the matching parameter threshold, the candidate configuration file is determined as the target configuration file.

7. The method according to claim 6, characterized in that, The parameters for detecting the matching between the candidate configuration file and the target business information include: Extract a set of configuration parameters from the candidate configuration file, wherein the set of configuration parameters includes at least the base station model parameters, base station software version parameters, base station management address parameters, and base station test scenario parameters supported by the candidate configuration file. The base station management address parameters are used to connect to the base station, and the base station test scenario parameters are used to indicate the test environment conditions that need to be met during the test of the base station. The matching degree between the configuration values ​​of each configuration parameter included in the configuration parameter set and the parameter values ​​of each operating parameter included in the operating parameter set of the target base station is detected to obtain each intermediate matching value. The target service information includes the operating parameter set, which includes at least the base station model parameter, base station software version parameter, base station management address parameter, and base station operating scenario parameter of the target base station. The base station operating scenario parameter is used to indicate the current operating environment of the target base station. The matching parameters are determined based on each of the intermediate matching values.

8. A testing device for a base station, characterized in that, A testing device applied to a target base station, the device comprising: The filtering module is used to filter out target test items that match the target base station from various test items stored in the test item library of the test equipment according to the reference base station information of the target base station. The reference base station information is used to indicate the services supported by the target base station, and different test items are used to test base stations that support different services. The lookup module is used to search for the target configuration file of the target test project that matches the target base station from the various configuration files stored in the test project library based on the target service information of the target base station. The target service information is used to characterize the handling method of the supported services of the target base station, and the target configuration file is used to characterize the operation mode of multiple test cases included in the target test project. Each test case is used to perform service testing on a service function of the base station. The testing module is used to test the target base station according to the target configuration file and the target test items.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method of any one of claims 1 to 7 through the computer program.

Images