Method and device for testing local module of edge device, electronic device and storage medium

Abstract

The invention discloses a test method and device for a local module of an edge device, electronic equipment and a storage medium, and the method comprises the steps: classifying test cases, and generating a concurrent test case set and a non-concurrent test case set; distributing a thread for the to-be-tested local module, so that the to-be-tested local module executes the test case in the thread to generate a concurrent test result; sending a networking configuration signal to a to-be-tested local module according to the test cases needing networking in the non-concurrent test case set, so that the to-be-tested local module is switched to an isolation detection position for subsequent testing to generate a first non-concurrent test result; for each test case which cannot run independently in the non-concurrent test case set, providing dependency data required by the test case which cannot run independently for the local module to be tested for subsequent testing, and generating a second non-concurrent test result; and generating a test report according to the test result. By implementing the invention, the testing efficiency of the local module of the edge equipment can be improved.

Description

Technical Field

[0001] The present invention relates to the field of electric power technology, and in particular to a testing method, device, electronic device and storage medium for a local module of an edge device. Background Art

[0002] In modern power systems, local modules of edge devices play a vital role. Edge devices are usually deployed on-site and are responsible for real-time data collection, processing and transmission. As core components, their local modules can perform local computing, storage and communication tasks, ensuring that edge devices can independently perform certain functions without relying entirely on central servers. Especially in the fields of power, smart home, industrial automation, etc., local modules of edge devices not only help reduce latency, but also greatly reduce the bandwidth required for data transmission, and optimize the response speed and reliability of the entire system. Therefore, it is particularly important to effectively test the local modules of edge devices. By comprehensively testing the local modules, it is possible to ensure their stable operation in various working environments, verify their ability to process data and perform control tasks, and detect potential problems in a timely manner.

[0003] However, the existing local module testing method of edge devices mainly relies on the serial execution method. In this test method, each test case must be executed one by one, and the connection between the module to be tested and the test device can only be carried out one by one. Although this serial execution method is simple, it is inefficient, especially when faced with a large number of modules to be tested and complex test cases. The test cycle is long and the resource utilization rate is low. Therefore, the existing technology has the limitation of not being able to execute multiple test cases at the same time in the testing of local modules of edge devices, resulting in the overall test efficiency being unable to meet the needs of large-scale and rapid verification. Summary of the invention

[0004] The embodiment of the present invention provides a method, device, electronic device and storage medium for testing a local module of an edge device. By implementing the present invention, the testing efficiency of the local module of the edge device can be improved.

[0005] An embodiment of the present invention provides a method for testing a local module of an edge device, comprising:

[0006] Obtain several test cases and local modules to be tested of edge devices;

[0007] Classify test cases according to their types, classify test cases that do not require networking and can be run independently as concurrent test case sets, and classify test cases that require networking or cannot be run independently as non-concurrent test case sets, and generate concurrent test case sets and non-concurrent test case sets;

[0008] According to the number of test cases in the concurrent test case set, a corresponding number of threads are allocated to the local module to be tested, so that the local module to be tested executes one test case in each thread to generate concurrent test results;

[0009] For each test case that requires networking in the non-concurrent test case set, a networking configuration signal is sent to the local module to be tested, so that the local module to be tested switches to the isolation check position; the test cases that require networking are sequentially placed in the execution queue, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that requires networking from the execution queue each time through the thread and performs the test, thereby generating a first non-concurrent test result;

[0010] For each test case that cannot be run independently in the non-concurrent test case set, after providing the dependency data required by the test case that cannot be run independently to the local module to be tested, the test cases that cannot be run independently are sequentially placed in the execution queue, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that cannot be run independently from the execution queue through the thread each time and performs the test, thereby generating a second non-concurrent test result;

[0011] A test report is generated according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result.

[0012] Furthermore, after obtaining a number of test cases and local modules to be tested of the edge device, it also includes:

[0013] Back up the data and working environment of the local module to be tested and generate a backup file.

[0014] Further, after generating a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result, the method further includes:

[0015] Restore the data and working environment of the local module to be tested according to the backup file.

[0016] Further, a test report is generated according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result, including:

[0017] Eliminate duplicate log information in the concurrent test results, the first non-concurrent test results, and the second non-concurrent test results to generate cleaned test results;

[0018] Format the cleaned test results and generate a test report.

[0019] An embodiment of the present invention provides a testing device for a local module of an edge device, a data acquisition module, a test case classification module, a concurrent test execution module, a non-concurrent test execution module and a test report generation module;

[0020] The data acquisition module is used to acquire a number of test cases and local modules to be tested of edge devices;

[0021] The test case classification module is used to classify the test cases according to their types, classify the test cases that do not require networking and can be run independently as concurrent test case sets, classify the test cases that require networking or cannot be run independently as non-concurrent test case sets, and generate concurrent test case sets and non-concurrent test case sets;

[0022] The concurrent test execution module is used to allocate a corresponding number of threads to the local module to be tested according to the number of test cases in the concurrent test case set, so that the local module to be tested executes one test case in each thread to generate a concurrent test result;

[0023] The non-concurrent test execution module is used to send a networking configuration signal to the local module to be tested for each test case that requires networking in the non-concurrent test case set, so that the local module to be tested switches to the isolation check position; put the test cases that require networking into the execution queue in sequence, and allocate a thread to the local module to be tested, so that the local module to be tested obtains a test case that requires networking from the execution queue through the thread each time and performs the test, thereby generating a first non-concurrent test result; for each test case that cannot be run independently in the non-concurrent test case set, after providing the local module to be tested with the dependency data required by the test case that cannot be run independently, the test cases that cannot be run independently are put into the execution queue in sequence, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that cannot be run independently from the execution queue through the thread each time and performs the test, thereby generating a second non-concurrent test result;

[0024] The test report generating module is used to generate a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result.

[0025] Furthermore, after obtaining a number of test cases and local modules to be tested of the edge device, it also includes:

[0026] Back up the data and working environment of the local module to be tested and generate a backup file.

[0027] Further, after generating a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result, the method further includes:

[0028] Restore the data and working environment of the local module to be tested according to the backup file.

[0029] Further, a test report is generated according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result, including:

[0030] Eliminate duplicate log information in the concurrent test results, the first non-concurrent test results, and the second non-concurrent test results to generate cleaned test results;

[0031] Format the cleaned test results and generate a test report.

[0032] Based on the above method embodiment, the present invention provides a corresponding electronic device embodiment.

[0033] An embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for testing the local module of an edge device described in any one of the above method embodiments can be implemented.

[0034] Based on the above method item embodiments, the present invention provides a corresponding storage medium item embodiment.

[0035] An embodiment of the present invention provides a storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for testing a local module of an edge device described in any one of the above method embodiments can be implemented.

[0036] Compared with the prior art, the present invention has the following beneficial effects:

[0037] The embodiment of the present invention provides a test method, device, electronic device and storage medium for a local module of an edge device. The method divides the test cases into two categories: concurrent test cases and non-concurrent test cases according to the type of test cases, executes the concurrent test cases first, improves the test efficiency by executing multiple test cases at the same time, and then executes the non-concurrent test cases to ensure the stability and accuracy of the test process. During the test process, the working environment and data of the local module to be tested are backed up, and the local module state is restored after the test is completed to ensure that the test does not affect the normal operation of the edge device. A test report is generated according to the test results to provide data support for subsequent edge device optimization and debugging. The simultaneous execution of concurrent test cases avoids the inefficiency of one-by-one execution in traditional serial tests, especially when facing a large number of modules to be tested and complex test cases, the test time can be significantly shortened; while non-concurrent tests ensure the stability and accuracy of the test by switching the isolation check bit, effectively avoiding the uncertainty of the test results. The test efficiency of the local module of the edge device is significantly improved by the mixed execution of concurrent and non-concurrent test cases. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1It is a flowchart of a method for testing a local module of an edge device provided by an embodiment of the present invention.

[0039] Figure 2 It is a structural diagram of a testing device for a local module of an edge device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0040] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0041] like Figure 1 As shown, an embodiment of the present invention provides a method for testing a local module of an edge device, which at least includes the following steps:

[0042] Step S1, obtaining several test cases and local modules to be tested of edge devices;

[0043] Exemplarily, the test cases include: module identification test, file synchronization test, data transmission stability test, environmental adaptability test, hardware response test, basic command response test, network configuration verification, single module communication performance test, protocol consistency test, abnormal scenario test, safety performance test and equipment linkage test; the local modules to be tested of the edge device include: micro-power wireless communication module and power line carrier module;

[0044] It is understandable that by obtaining several test cases and the local modules to be tested of the edge device, the foundation can be laid for the entire test process, the test objects and test contents can be clarified, and the pertinence and completeness of the test can be ensured. The comprehensiveness of the test cases can cover the multi-dimensional performance of the module in terms of functionality, stability, security, etc., reducing the risk of missing key test scenarios; and the clear positioning of the local modules to be tested of the edge device can customize the test strategy according to the characteristics of different modules, improving the pertinence and efficiency of the test.

[0045] In a preferred embodiment, after obtaining several test cases and local modules to be tested of edge devices, the method further includes:

[0046] Back up the data and working environment of the local module to be tested and generate a backup file.

[0047] Specifically, back up the data and working environment of the local module to be tested, including its current configuration parameters, operating status, stored data, and external environment information it depends on, and generate a complete backup file. Specifically, first read and save the key configuration files and log data of the module to ensure a comprehensive record of the current working status; then collect the external environment data that interacts with the module, such as network configuration, connection device information, and power status; finally, organize and compress the above information to generate a backup file in a unified format, and verify and store the backup file. This step ensures that during the test, even if an unexpected situation occurs, the module and environment can be quickly restored to the initial state by restoring the backup file, thereby ensuring the repeatability and reliability of the test.

[0048] Step S2: classify the test cases according to their types, classify the test cases that do not require networking and can be run independently as concurrent test case sets, and classify the test cases that require networking or cannot be run independently as non-concurrent test case sets, thereby generating concurrent test case sets and non-concurrent test case sets;

[0049] It should be noted here that the test cases are classified according to their types. First, the requirements and execution conditions of each test case are identified. Those test cases that do not require networking and can run in an independent environment are classified as concurrent test case sets. These test cases can be executed in parallel in multiple threads without interfering with each other, so they are suitable for efficient concurrent testing. Then, the remaining test cases are analyzed. If the test cases require specific networking operations or rely on the collaboration of multiple modules, or their execution environment requires specific conditions to be met, such as relying on external devices or complex data input, these test cases are classified as non-concurrent test case sets. The test cases in the non-concurrent test case set must be executed in sequence or under specific conditions, so they are not suitable for parallel execution. Through this classification process, concurrent test case sets and non-concurrent test case sets are generated, which provide clear guidance for the execution order and method of subsequent tests, ensuring the efficient and accurate execution of test tasks.

[0050] Step S3: according to the number of test cases in the concurrent test case set, a corresponding number of threads are allocated to the local module to be tested, so that the local module to be tested executes one test case in each thread to generate a concurrent test result;

[0051] Specifically, according to the number of test cases in the concurrent test case set, threads equal to the number of test cases are allocated to the local module to be tested. Each thread is responsible for executing a test case to ensure that each concurrent test case can be carried out independently and in parallel. The specific steps include: first, according to the hardware resources and concurrent capabilities of the system, the number of threads is reasonably allocated to avoid exhaustion of system resources or excessive load caused by too many threads; then, each thread is started and the corresponding test case is allocated to each thread. When each thread executes the corresponding test case, the local module to be tested independently performs test operations according to the test requirements, such as data processing, performance verification or function verification. Through multi-threaded concurrent execution, the test efficiency can be significantly improved, the test cycle can be reduced, and concurrent test results can be generated in real time. Finally, the test results of each thread are summarized to comprehensively analyze and evaluate the execution of the test case.

[0052] Step S4: for each test case requiring networking in the non-concurrent test case set, a networking configuration signal is sent to the local module to be tested, so that the local module to be tested switches to the isolation check position; the test cases requiring networking are sequentially placed in the execution queue, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case requiring networking from the execution queue through the thread each time and performs the test, thereby generating a first non-concurrent test result;

[0053] In actual operation, for each test case that needs networking in the non-concurrent test case set, the networking requirements of the case are first analyzed, including the device type, networking protocol and network topology involved. Then, a networking configuration signal is sent to the local module to be tested to ensure that the local module to be tested can be switched to the isolation check position according to the configuration and successfully networked with other devices or modules. In this process, the network environment of the local module to be tested will be adjusted to simulate the networking scenario in actual operation. Next, all test cases that need networking are put into the execution queue in turn to ensure that each test case is executed in sequence after the network environment is prepared. A thread is assigned to each test case, and thread management is used to ensure that a test case is obtained and executed from the queue each time. Each thread is responsible for executing the corresponding networking operation and verifying the performance, stability and reliability of the module to be tested in the networking environment. After execution, the first non-concurrent test results are generated, which contain various test indicators of the local module to be tested in the networking environment, including but not limited to network connection quality, communication delay, bandwidth utilization and data transmission stability.

[0054] Step S5: for each test case that cannot be run independently in the non-concurrent test case set, after providing the dependency data required by the test case that cannot be run independently to the local module to be tested, the test cases that cannot be run independently are sequentially placed in the execution queue, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that cannot be run independently from the execution queue through the thread each time and performs the test, thereby generating a second non-concurrent test result;

[0055] It should be noted here that for each test case that cannot be run independently in the non-concurrent test case set, the dependency relationship of the test case is first identified, including necessary conditions such as hardware, software or data input. According to the requirements of the test case, the corresponding dependency data is provided to the local module to be tested. These data may include pre-prepared configuration files, external data sources, or intermediate data output by other modules to ensure the integrity of the test environment. After all the dependent data are prepared, these test cases that cannot be run independently are placed in the execution queue in turn to ensure that each test case can be executed in the set order. In order to ensure the smooth progress of the test process, an independent thread is assigned to each test case, and each thread is responsible for obtaining a test case from the execution queue and executing it. Each thread will test the local module to be tested according to the specific requirements of the corresponding test case during the execution process. These tests may involve aspects such as the interaction between the module and the external system, data processing capabilities, and response to dependent data, to ensure that the performance of the module in the actual operating environment meets expectations. After execution, the second non-concurrent test results are generated. These results include the performance of the local module to be tested under dependent data and environmental conditions, covering key indicators such as data processing capabilities, response time, and stability.

[0056] Step S6: Generate a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result.

[0057] In a preferred embodiment, generating a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result includes:

[0058] Eliminate duplicate log information in the concurrent test results, the first non-concurrent test results, and the second non-concurrent test results to generate cleaned test results;

[0059] Format the cleaned test results and generate a test report.

[0060] Specifically, the step of removing duplicate log information from the concurrent test results, the first non-concurrent test results, and the second non-concurrent test results first requires integrating the log information in all test results. The log files of the concurrent test, the first non-concurrent test, and the second non-concurrent test are merged into an overall data set to ensure that the log information generated in all test processes can be uniformly processed by the system. On this basis, the merged log data is analyzed using a deduplication algorithm to identify duplicate log information. Duplicate log information may include the same error message, status report, the same operation record, or other redundant content, which is usually triggered repeatedly by multiple threads or test cases during execution. By comparing key fields such as the timestamp, event identifier, and test case identifier of the log entry, the system can automatically determine which log information is duplicated. Once the duplicate log is identified, the system will remove it and retain a unique record of each event or state. This process not only reduces data redundancy, but also improves the efficiency of subsequent data analysis and avoids misjudgment or data deviation caused by duplicate data. After removing duplicate logs, cleaned test results are generated. These results contain accurate, concise and non-duplicate log information, providing more accurate data support for subsequent test analysis and report generation.

[0061] After removing duplicate log information, the system will format the cleaned log data. The formatting process includes structuring the log information, unifying the log format and field standards, so that it is convenient for subsequent analysis and display. The formatted test results will be output according to the predetermined standards, for example, the results and key data of each test will be presented in the form of tables, charts, or hierarchical reports. This not only helps to clearly display various types of information during the test process, but also makes it easier for project leaders or developers to quickly view and understand the test results.

[0062] Optionally, after generating a test report according to the concurrent test result, the first non-concurrent test result, and the second non-concurrent test result, the method further includes:

[0063] Restore the data and working environment of the local module to be tested according to the backup file.

[0064] It should be noted here that when restoring the data and working environment of the local module to be tested according to the backup file, it is first necessary to verify the integrity and validity of the backup file to ensure that no critical data is damaged or lost during the backup process. The recovery process usually includes two parts: data recovery and working environment recovery. In terms of data recovery, the system extracts relevant data files from the backup file and reloads them into the local module to be tested. These data may include module configuration files, historical test data, device status information, etc. The recovery process needs to ensure that the data format is correct and compatible with the current module version. In addition, during the data recovery process, specific data mapping and conversion may be required according to the module type and test requirements to ensure that the restored data can correctly support subsequent test tasks. In terms of working environment recovery, the system needs to rebuild the module's operating environment, including operating system configuration, network settings, external device interface configuration, etc. According to the environment settings in the backup file, the system environment of the module to be tested is restored to its state before the test. This may involve restoring specific network configurations, hardware drivers, software libraries and their versions, etc., to ensure that the module to be tested is tested in the same working environment to ensure the consistency and reliability of the test results. The entire recovery process needs to be strictly executed to avoid data loss or environmental inconsistency, and to ensure that the module under test can continue to perform subsequent test tasks under the same conditions as the initial test state.

[0065] Based on the above method embodiment, the present invention provides a corresponding device embodiment.

[0066] like Figure 2 As shown, an embodiment of the present invention provides a testing device for a local module of an edge device, including: a data acquisition module 101, a test case classification module 102, a concurrent test execution module 103, a non-concurrent test execution module 104 and a test report generation module 105.

[0067] The data acquisition module 101 is used to acquire a number of test cases and local modules to be tested of edge devices;

[0068] The test case classification module 102 is used to classify the test cases according to their types, classify the test cases that do not require networking and can be run independently as concurrent test case sets, classify the test cases that require networking or cannot be run independently as non-concurrent test case sets, and generate concurrent test case sets and non-concurrent test case sets;

[0069] The concurrent test execution module 103 is used to allocate a corresponding number of threads to the local module to be tested according to the number of test cases in the concurrent test case set, so that the local module to be tested executes one test case in each thread to generate a concurrent test result;

[0070] The non-concurrent test execution module 104 is used to send a networking configuration signal to the local module to be tested for each test case that requires networking in the non-concurrent test case set, so that the local module to be tested switches to the isolation check position; put the test cases that require networking into the execution queue in sequence, and allocate a thread to the local module to be tested, so that the local module to be tested obtains a test case that requires networking from the execution queue through the thread each time and performs the test, thereby generating a first non-concurrent test result; for each test case that cannot be run independently in the non-concurrent test case set, after providing the local module to be tested with the dependency data required by the test case that cannot be run independently, the test cases that cannot be run independently are put into the execution queue in sequence, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that cannot be run independently from the execution queue each time through the thread and performs the test, thereby generating a second non-concurrent test result;

[0071] The test report generating module 105 is used to generate a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result.

[0072] In a preferred embodiment, the testing device for the local module of the edge device, after obtaining a plurality of test cases and the local module to be tested of the edge device, further comprises:

[0073] Back up the data and working environment of the local module to be tested and generate a backup file.

[0074] Preferably, the testing device of the local module of the edge device, after generating a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result, further comprises:

[0075] Restore the data and working environment of the local module to be tested according to the backup file.

[0076] In an optional embodiment, the testing device of the local module of the edge device generates a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result, including:

[0077] Eliminate duplicate log information in the concurrent test results, the first non-concurrent test results, and the second non-concurrent test results to generate cleaned test results;

[0078] Format the cleaned test results and generate a test report.

[0079] It should be noted that the embodiments of the device described above correspond to the above embodiments of the present invention, and can implement any of the methods described above in the present invention. In addition, the embodiments of the above-mentioned device are merely schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present invention, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0080] Based on the above method embodiment of the present invention, a corresponding electronic device embodiment is provided.

[0081] An embodiment of the present invention provides an electronic device, comprising a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, the test method of the local module of the edge device described in any one of the present invention is implemented, or, when the processor executes the computer program, the functions of each module in the above-mentioned device embodiments are implemented.

[0082] Exemplarily, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to implement the present invention. The one or more modules may be a series of computer program instruction segments capable of implementing specific functions, which are used to describe the execution process of the computer program in the terminal device.

[0083] The terminal device may be a computing device such as a desktop computer, a notebook, a PDA, a cloud server, etc. The terminal device may include, but is not limited to, a processor and a memory.

[0084] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the terminal device, and uses various interfaces and lines to connect various parts of the entire terminal device.

[0085] The memory can be used to store the computer program and / or module, and the processor realizes various functions of the terminal device by running or executing the computer program and / or module stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created according to the use of the mobile phone, etc. In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (SecureDigital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0086] Based on the above method embodiment, the present invention provides a storage medium embodiment;

[0087] Another embodiment of the present invention provides a storage medium, which includes a stored computer program, wherein when the computer program is running, the device where the storage medium is located is controlled to execute the test method of the local module of any edge device described above in the present invention.

[0088] The storage medium is a computer-readable storage medium, and the computer program includes computer program code, which may be in source code form, object code form, executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0089] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.

[0090] The above is a preferred embodiment of the present invention. It should be pointed out that a person skilled in the art can make several improvements and modifications without departing from the principle of the present invention. These improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for testing a local module of an edge device, characterized in that: include: Obtain several test cases and local modules to be tested of edge devices; Classify test cases according to their types, classify test cases that do not require networking and can be run independently as concurrent test case sets, and classify test cases that require networking or cannot be run independently as non-concurrent test case sets, and generate concurrent test case sets and non-concurrent test case sets; According to the number of test cases in the concurrent test case set, a corresponding number of threads are allocated to the local module to be tested, so that the local module to be tested executes one test case in each thread to generate concurrent test results; For each test case that requires networking in the non-concurrent test case set, a networking configuration signal is sent to the local module to be tested, so that the local module to be tested switches to the isolation check position; the test cases that require networking are sequentially placed in the execution queue, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that requires networking from the execution queue each time through the thread and performs the test, thereby generating a first non-concurrent test result; For each test case that cannot be run independently in the non-concurrent test case set, after providing the dependency data required by the test case that cannot be run independently to the local module to be tested, the test cases that cannot be run independently are sequentially placed in the execution queue, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that cannot be run independently from the execution queue through the thread each time and performs the test, thereby generating a second non-concurrent test result; A test report is generated according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result.

2. A method for testing a local module of an edge device as claimed in claim 1, characterized in that: After obtaining several test cases and the local modules to be tested of the edge device, it also includes: Back up the data and working environment of the local module to be tested and generate a backup file.

3. A method for testing a local module of an edge device as claimed in claim 2, characterized in that: After generating a test report according to the concurrent test result, the first non-concurrent test result, and the second non-concurrent test result, the method further includes: Restore the data and working environment of the local module to be tested according to the backup file.

4. A method for testing a local module of an edge device as claimed in claim 3, characterized in that: A test report is generated according to the concurrent test result, the first non-concurrent test result, and the second non-concurrent test result, including: Eliminate duplicate log information in the concurrent test results, the first non-concurrent test results, and the second non-concurrent test results to generate cleaned test results; Format the cleaned test results and generate a test report.

5. A testing device for a local module of an edge device, characterized in that: include: Data acquisition module, test case classification module, concurrent test execution module, non-concurrent test execution module and test report generation module; The data acquisition module is used to acquire a number of test cases and local modules to be tested of edge devices; The test case classification module is used to classify the test cases according to their types, classify the test cases that do not require networking and can be run independently as concurrent test case sets, classify the test cases that require networking or cannot be run independently as non-concurrent test case sets, and generate concurrent test case sets and non-concurrent test case sets; The concurrent test execution module is used to allocate a corresponding number of threads to the local module to be tested according to the number of test cases in the concurrent test case set, so that the local module to be tested executes one test case in each thread to generate a concurrent test result; The non-concurrent test execution module is used to send a networking configuration signal to the local module to be tested for each test case that requires networking in the non-concurrent test case set, so that the local module to be tested switches to the isolation check position; put the test cases that require networking into the execution queue in sequence, and allocate a thread to the local module to be tested, so that the local module to be tested obtains a test case that requires networking from the execution queue through the thread each time and performs the test, thereby generating a first non-concurrent test result; for each test case that cannot be run independently in the non-concurrent test case set, after providing the local module to be tested with the dependency data required by the test case that cannot be run independently, the test cases that cannot be run independently are put into the execution queue in sequence, and a thread is allocated to the local module to be tested, so that the local module to be tested obtains a test case that cannot be run independently from the execution queue through the thread each time and performs the test, thereby generating a second non-concurrent test result; The test report generating module is used to generate a test report according to the concurrent test result, the first non-concurrent test result and the second non-concurrent test result.

6. A testing device for a local module of an edge device as claimed in claim 5, characterized in that: After obtaining several test cases and the local modules to be tested of the edge device, it also includes: Back up the data and working environment of the local module to be tested and generate a backup file.

7. A testing device for a local module of an edge device as claimed in claim 6, characterized in that: After generating a test report according to the concurrent test result, the first non-concurrent test result, and the second non-concurrent test result, the method further includes: Restore the data and working environment of the local module to be tested according to the backup file.

8. A testing device for a local module of an edge device as claimed in claim 7, characterized in that: A test report is generated according to the concurrent test result, the first non-concurrent test result, and the second non-concurrent test result, including: Eliminate duplicate log information in the concurrent test results, the first non-concurrent test results, and the second non-concurrent test results to generate cleaned test results; Format the cleaned test results and generate a test report.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method for testing the local module of the edge device as described in any one of claims 1 to 4 can be implemented.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it can implement the testing method of the local module of the edge device described in any one of claims 1 to 4.

Images