A synchronization test method for a distributed internet-of-things terminal and related equipment

Abstract

The application discloses a kind of distributed IOT terminal synchronous test method and related equipment, method includes: comparing with acquisition cloud version number and local version number;If cloud version number is higher than local version number, cloud test case corresponding to cloud version number is used as first test case, closed loop test is carried out according to first test case to IOT terminal, and local test case is updated according to cloud test case;If cloud version number is lower than or equal to local version number, local test case corresponding to local version number is used as first test case to carry out closed loop test to IOT terminal;If cloud version number is lower than local version number, local test case is uploaded to cloud platform.The embodiment of the application carries out unified management to test case by the comparison result of cloud test case and local test case, realizes the synchronization of test case in cloud and local, and can improve the consistency of test result.The application can be widely applied in power distribution terminal test field.

Description

Technical Field

[0001] This application relates to the field of power distribution terminal testing technology, and in particular to a synchronous testing method and related equipment for distributed Internet of Things terminals. Background Technology

[0002] Smart distribution networks require the integration of diverse distribution IoT terminals into the constructed IoT platform, and the testing of these terminals to verify their functionality and equipment performance. Existing technical solutions typically employ manual methods to test different types of distribution IoT terminals, resulting in inconsistent test results. Summary of the Invention

[0003] The main objective of this application is to propose a synchronous testing method and related equipment for distributed IoT terminals, which can improve the consistency of test results.

[0004] To achieve the above objectives, one aspect of this application proposes a synchronous testing method for distributed IoT terminals, applied to a joint debugging warehouse, the method comprising: The cloud version number and the local version number are compared. If the cloud version number is higher than the local version number, determine the cloud test case corresponding to the cloud version number, use the cloud test case as the first test case, and update the local test case according to the cloud test case; If the cloud version number is lower than or equal to the local version number, determine the local test case corresponding to the local version number and use the local test case as the first test case; if the cloud version number is lower than the local version number, upload the local test case to the cloud platform. Based on the first test case and the terminal device, a closed-loop test is performed to determine the test results.

[0005] In some embodiments, the step of performing closed-loop testing based on the first test case and the terminal device to determine the test result specifically includes: A test instruction is generated based on the first test case, and the test instruction is sent to the test device so that the test device can test the terminal device according to the test instruction and collect test data. The test data is compared and analyzed with the test instructions to determine the test result.

[0006] To achieve the above objectives, another aspect of this application proposes a synchronous testing method for distributed IoT terminals, applied to a cloud platform, the method comprising: The received editing information is analyzed to determine the current editing node information, and a locked editing permission is generated based on the editing node information. An editing permission flag is then issued based on the locked editing permission. A second test case and its corresponding target version number are generated based on the edit license flag and the edit node information; Store the second test case and the target version number in the current editing node.

[0007] In some embodiments, generating a second test case and a corresponding target version number based on the editing license flag and the editing node information specifically includes: The test case is edited according to the editing permission mark, the target test device type and initial version number are determined, and the target test plan is determined by matching the target test device type with the preset test plan library. Based on the analysis of the test cases and the target test plan, the target test item information and the target test state sequence are determined; and based on the equipment test requirements and the target test state sequence, the target test model is determined. The second test case is generated based on the target test model, the target test item information, the target test state sequence, and the target test plan. The initial version number is then updated based on the second test case to determine the target version number.

[0008] In some embodiments, updating the initial version number based on the second test case to determine the target version number specifically includes: The second test case was analyzed to determine the changes in the state sequence, the changes in the test items, and the changes in the test plan. The initial version number is updated based on the changes in the state sequence, the changes in the test items, the changes in the test plan, and the preset update rules to determine the target version number.

[0009] In some embodiments, the method further includes: The cloud test case is updated based on the second test case and the target version number.

[0010] To achieve the above objectives, another aspect of this application proposes a synchronous testing system for distributed IoT terminals. The system includes a joint testing warehouse and a cloud platform, wherein... The joint debugging repository is used to execute the method described above, generate a lock editing permission application, a second test case, and a target version number, and send the lock editing permission application, the second test case, and the target version number to the cloud platform; wherein, the joint debugging repository includes several terminal devices; The cloud platform is used to execute the method described above, generate an editing flag based on the locked editing permission application, send the editing flag to the joint debugging repository, and update the cloud test case according to the second test case and the target version number.

[0011] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0012] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0013] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods described above. The embodiments of this application include at least the following beneficial effects: This application provides a method, system, electronic device, storage medium, and program product for synchronous testing of distributed IoT terminals. This solution parses acquired cloud test cases and local test cases to determine the cloud version number corresponding to the cloud test case and the local version number corresponding to the local test case, and compares the cloud version number with the local version number. If the cloud version number is higher than the local version number, the cloud test case is used as the first test case for closed-loop testing of the IoT terminal, and the local test case is updated according to the cloud test case corresponding to the cloud version number. If the cloud version number is lower than or equal to the local version number, the local test case is used as the first test case for closed-loop testing of the IoT terminal, and the local test case is uploaded to the cloud platform. By using the comparison results of cloud test cases and local test cases, test cases are managed uniformly, achieving synchronization between the cloud and local test cases and improving the consistency of test results. Attached Figure Description

[0014] Figure 1 This is a flowchart of a synchronous testing method for a distributed IoT terminal provided in an embodiment of this application; Figure 2 yes Figure 1 The flowchart of step S104 in the process; Figure 3 This is a flowchart illustrating the editing of test cases in a synchronous testing method for distributed IoT terminals provided in an embodiment of this application; Figure 4 yes Figure 3 The flowchart of step S302 in the document; Figure 5 yes Figure 4 The flowchart of step S403 in the process; Figure 6 This is a structural block diagram of a distributed heterogeneous testing system in a specific embodiment provided in this application. Figure 7 This is a schematic diagram of a cloud-edge-device architecture according to a specific embodiment provided in this application. Figure 8 This is a flowchart illustrating test case synchronization in a specific embodiment provided in this application. Figure 9 This is a flowchart illustrating the construction of test cases in a specific embodiment provided in this application. Figure 10 This is a schematic diagram of the structure of a synchronous testing system for distributed IoT terminals provided in an embodiment of this application; Figure 11 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0016] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0017] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0019] Figure 1 This is an optional flowchart of a synchronous testing method for distributed IoT terminals provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S104.

[0020] Step S101: Obtain the cloud version number and the local version number, and compare the cloud version number and the local version number; Step S102: If the cloud version number is higher than the local version number, determine the cloud test case corresponding to the cloud version number, use the cloud test case as the first test case, and update the local test case according to the cloud test case. Step S103: If the cloud version number is lower than or equal to the local version number, determine the local test case corresponding to the local version number and use the local test case as the first test case; if the cloud version number is lower than the local version number, upload the local test case to the cloud platform. Step S104: Perform closed-loop testing based on the first test case and the terminal device, and determine the test results.

[0021] Steps S101 to S104 as illustrated in this embodiment involve obtaining cloud test cases stored on a cloud platform, parsing both the cloud test cases and locally stored test cases to determine the cloud version number corresponding to the cloud test cases and the local version number corresponding to the local test cases; comparing the parsed cloud version number with the local version number to determine if the local test cases and cloud test cases are synchronized; if the cloud version number is higher than the local version number, version synchronization of the test cases is required, updating the local test cases according to the cloud test cases, and performing closed-loop testing on the IoT terminal according to the cloud test cases or the updated local test cases to obtain... The test results correspond to the IoT terminal. Conversely, if the cloud version number is lower than or equal to the local version number, it is determined that there is no need to synchronize the test cases. Closed-loop testing is performed on the IoT terminal based on the local test cases to obtain the corresponding test results. At the same time, in order to ensure that the test cases used by other nodes in the distributed IoT terminal system remain synchronized, the local test cases are uploaded to the cloud center. The cloud center updates the cloud test cases based on the received local test cases. Other nodes in the distributed IoT terminal system obtain the cloud test cases through the cloud center, compare them with the local test cases of each node, and update their local test cases, thereby achieving test case synchronization and improving the consistency of test results.

[0022] Please see Figure 2 In some embodiments, step S104 may include, but is not limited to, steps S201 to S202: Step S201: Generate test instructions based on the first test case, and send the test instructions to the test device so that the test device can test the terminal device according to the test instructions and collect test data; Step S202: Compare and analyze the test data with the test instructions to determine the test results.

[0023] In step S201 of some embodiments, the test system determines the test cases for testing the power distribution IoT terminal by comparing the cloud test cases and local test cases on the cloud platform; the test system generates corresponding test instructions based on the determined test cases and sends the generated test instructions to the terminal device. In this embodiment, the terminal device includes a power source or a simulation terminal. The terminal device drives the power source to generate a power source signal to test the IoT terminal according to the received test instructions, or starts the simulation terminal to perform simulation and collects test data through sensors or simulation sensors.

[0024] In step S202 of some embodiments, the testing system analyzes and compares the test data collected by the sensor with the test instructions to determine whether the test data of the IoT terminal meets the requirements of the test instructions, and then obtains the test results. In this embodiment, the sensor uploads the collected test data to the smart gateway, the smart gateway uploads the received test data to the global IoT platform, the cloud testing center collects data from the global IoT platform, and then forwards it to the testing system. The testing system analyzes and compares the forwarded test data with the test instructions to obtain the test results.

[0025] Please see Figure 3 In some embodiments, the synchronization testing method for a distributed IoT terminal provided in this application may also include, but is not limited to, steps S301 to S303: Step S301: Analyze the received editing information, determine the current editing node information, generate locked editing permissions based on the editing node information, and issue an editing permission flag based on the locked editing permissions; Step S302: Generate a second test case and its corresponding target version number based on the editing license mark and editing node information; Step S303: Store the second test case and the target version number in the current editing node.

[0026] In step S301 of some embodiments, the test system can test the distribution IoT terminal based on the synchronized local test cases, and can also edit the local test cases to achieve test case synchronization of each node in the distributed distribution IoT terminal system. In this embodiment, the test system has the function and permission to edit local test cases. To avoid interference caused by multiple node test systems in the distributed distribution IoT terminal system editing local test cases at the same time, in this embodiment, only one node test system in the distributed distribution IoT terminal system can perform test case editing at the same time. Therefore, the cloud platform is configured to manage locking permissions. After receiving the externally input editing information, the test system determines the node currently editing the test case and generates a corresponding lock editing permission application, which is sent to the cloud platform to request the lock editing permission. After receiving the lock editing permission application, the cloud platform checks the uniqueness of the permission. If no other node is editing the test case or has an editing flag, the cloud platform successfully accepts the lock editing permission application, returns the result to the test system, and issues the corresponding editing flag. At the same time, the cloud platform sets the stored cloud test case to the "editing in progress" flag.

[0027] In step S302 of some embodiments, after the test system receives the edit flag returned by the cloud platform, it generates an edited local test case, i.e., a second test case, based on the received edit information and the edit flag, as well as the version number information corresponding to the generated edited local test case, i.e., the target version number.

[0028] In step S303 of some embodiments, the test system will edit the new test case according to the editing information and generate the corresponding version number, which will be stored in the node of the current test system as the updated local test case.

[0029] Please see Figure 4 In some embodiments, step S302 may also include, but is not limited to, steps S401 to S403: Step S401: Edit the test case according to the editing license mark, determine the target test equipment type and initial version number, and match the target test equipment type with the preset test plan library to determine the target test plan; Step S402: Analyze the test cases and target test plans to determine the target test item information and target test state sequence; and analyze the equipment test requirements and target test state sequence to determine the target test model. Step S403: Generate a second test case based on the target test model, target test item information, target test state sequence, and target test plan, and update the initial version number based on the second test case to determine the target version number.

[0030] In step S401 of some embodiments, the test system parses the editing information according to the editing flag to determine the type of device under test (DUT) and the initial version number of the edited test case. Different types of DUTs have multiple different test schemes, thus editing or generating different test cases. In this embodiment, the types of DUTs include power distribution terminals, smart gateways, etc. The test system matches the determined DUT type with a preset test scheme library to determine the corresponding test scheme. For example, the test methods for power distribution terminals include arrival inspection schemes, network access inspection schemes, etc.

[0031] In step S402 of some embodiments, the test system analyzes the determined test plan and the input editing information to determine the test items included in the selected test plan. For example, the incoming inspection test plan selected for the power distribution terminal includes test items such as SNTP time synchronization, time accuracy, and voltage zero drift. Each test item contains multiple state sequences; that is, the test item is a set of multiple state sequences. For example, the voltage dead zone test item includes the state sequences shown in the table below: Table 1

[0032] After determining the test state sequence in the test project, the corresponding test model is determined according to the functional test requirements of the device under test and the determined test state sequence. In this embodiment, a general three-remote test model, a state sequence test model based on multiple cross-sectional data, and a fixed value dead zone model are designed; for smart gateway devices, a digital quantity simulation model is also set.

[0033] In step S403 of some embodiments, new test cases are generated based on the determined test model, test state sequence, test items and test plan; the test system updates the initial version number based on the obtained new test cases to obtain the version number corresponding to the test case. The test system can identify and distinguish test cases edited or stored at different nodes based on the version number.

[0034] Please see Figure 5 In some embodiments, step S403 may include, but is not limited to, steps S501 to S502: Step S501: Analyze the second test case and determine the change in state sequence, the change in test item, and the change in test plan respectively. Step S502: Update the initial version number based on the changes in the state sequence, the changes in the test items, the changes in the test plan, and the preset update rules to determine the target version number.

[0035] In step S501 of some embodiments, the test system analyzes the edited test cases to determine the changes in the test scheme, the changes in the test items, and the changes in the state sequence in the edited test cases; the test system updates the initial version number based on the obtained changes.

[0036] In step S502 of some embodiments, the testing system updates different parts of the initial version number based on the changes in the test plan, the test items, and the state sequence, according to the set update rules, to obtain the target version number. In this embodiment, the version number is divided into three segments, such as ABC, where A, B, and C are non-negative integers. Different segments correspond to different parts of the test cases: segment C corresponds to the change in the test state sequence, segment B corresponds to the change in the test items, and segment A corresponds to the change in the test plan. When the test state sequence value changes, or the number of state sequences increases or decreases, the value of segment C is incremented by one. Similarly, when the number of test plans and test items increases or decreases, segments A and B are also incremented by one. In this embodiment, the values ​​of each segment of the version number continuously increase to avoid duplication with historical data and interference.

[0037] The following is a detailed description and explanation of the solutions in the embodiments of the present invention, using specific application examples: Please see Figure 6 , Figure 6 This application describes a distributed heterogeneous testing system for synchronous testing of distributed IoT terminals, based on an embodiment of this application. The system includes a cloud-based testing platform and multiple joint debugging warehouses, i.e., a heterogeneous testing system. Each joint debugging warehouse includes a main control screen, several power distribution terminal test screens, and several smart gateway test screens. This distributed heterogeneous testing system is a large closed-loop testing system based on a cloud-edge-device architecture, as shown in Figure 7. In this architecture, the cloud includes an application layer and a platform layer; the edge layer includes the test benches and the objects under test in the joint debugging warehouses; and the device layer mainly consists of sensors and simulated sensors. When performing closed-loop testing on IoT terminals using this architecture, the closed-loop data flow process is as follows: the test bench issues commands to the power source or simulated terminal according to the test case; the power source signal is injected into the sensor; after the sensor is triggered, the smart gateway collects the sensor data and sends it to the global IoT platform; the cloud testing service center collects the data from the global IoT platform and forwards it to the test benches in the joint debugging warehouses; after receiving the forwarded data, the test benches analyze and compare it with the command data to obtain the test results. Please refer to [link to relevant documentation]. Figure 8The current joint testing warehouse edits new test cases based on the functional testing requirements of IoT terminal devices and synchronizes the edited test cases with the cloud testing platform and other joint testing warehouse nodes. The current joint testing warehouse node requests lock permissions from the cloud testing platform. Based on the uniqueness of the received permission requests, and after confirming that no other joint testing warehouse node is editing test cases or that no other joint testing warehouse node has an editing flag, the cloud testing platform accepts the request and returns it to the requesting joint testing warehouse node, setting the cloud testing platform's test cases to an editing flag. After receiving the accepted request, the joint testing warehouse node... Figure 9 The test case modeling process shown involves editing test cases, determining the type of device under test (DUT) in the joint debugging repository node (number of which is 1), and determining the corresponding number of test schemes and initial version numbers based on the type of DUT. For each determined test scheme, the required test items and their quantities for the DUT are determined, along with the corresponding number of test state sequences. Then, based on each test state sequence and the functional testing requirements of the DUT, a corresponding number of test models are selected, including ordinary remote sensing test models, state sequence test models based on multiple cross-sectional data, fixed-value dead-zone models, and digital quantity simulation models. Closed-loop testing is performed on the DUT using the selected test models, and the current and voltage state sequences, including amplitude and phase, are recorded. During the closed-loop test, the voltage and current states of the DUT are recorded and analyzed and compared with the set state sequences to determine the test results.

[0038] The embodiments of this application include at least the following beneficial effects: This application provides a method, system, electronic device, storage medium, and program product for synchronous testing of distributed IoT terminals. This solution parses acquired cloud test cases and local test cases to determine the cloud version number corresponding to the cloud test case and the local version number corresponding to the local test case, and compares the cloud version number with the local version number. If the cloud version number is higher than the local version number, the cloud test case is used as the first test case for closed-loop testing of the IoT terminal, and the local test case is updated according to the cloud test case corresponding to the cloud version number. If the cloud version number is lower than or equal to the local version number, the local test case is used as the first test case for closed-loop testing of the IoT terminal, and the local test case is uploaded to the cloud platform. By using the comparison results of cloud test cases and local test cases, test cases are managed uniformly, achieving synchronization between the cloud and local test cases and improving the consistency of test results.

[0039] Please see Figure 10 This application also provides a synchronous testing system for distributed IoT terminals, which can implement the above-mentioned method. The system includes a joint debugging warehouse and a cloud platform. The joint debugging repository is used to execute the method described above, generate a lock editing permission application, a second test case, and a target version number, and send the lock editing permission application, the second test case, and the target version number to the cloud platform; wherein, the joint debugging repository includes several terminal devices; The cloud platform is used to generate an editing flag based on the locked editing permission application, send the editing flag to the joint debugging repository, and update the cloud test case according to the second test case and the target version number.

[0040] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0041] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0042] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0043] Please see Figure 11 , Figure 11 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1101 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1102 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1102 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1102 and is called and executed by the processor 1101 using the methods described in the embodiments of this application. Input / output interface 1103 is used to implement information input and output; The communication interface 1104 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1105 transmits information between various components of the device (e.g., processor 1101, memory 1102, input / output interface 1103, and communication interface 1104); The processor 1101, memory 1102, input / output interface 1103 and communication interface 1104 are connected to each other within the device via bus 1105.

[0044] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0045] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0046] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0047] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0048] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0049] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0050] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0051] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0052] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0053] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification 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.

[0054] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0055] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0056] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0057] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0058] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0059] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A synchronization test method of a distributed Internet of Things terminal, applied to a joint debugging warehouse, the joint debugging warehouse comprising a plurality of power distribution test terminal devices, characterized in that, The method includes: Obtain the cloud version number and the local version number, and compare the cloud version number and the local version number; wherein, the cloud version number is the version number of the cloud test case stored on the cloud platform, and the local version number is the version number of the local test case stored locally; If the cloud version number is higher than the local version number, determine the cloud test case corresponding to the cloud version number, use the cloud test case as the first test case, and update the local test case according to the cloud test case; wherein, updating the local test case according to the cloud test case specifically includes: The received editing information is analyzed to determine the current editing node information, and an application is made to the cloud platform to lock editing permissions based on the editing information, so that the cloud platform issues an editing permission mark based on the locked editing permissions; A second test case and its corresponding target version number are generated based on the edit license flag and the edit node information; Store the second test case and the target version number in the current editing node; If the cloud version number is lower than or equal to the local version number, determine the local test case corresponding to the local version number and use the local test case as the first test case; if the cloud version number is lower than the local version number, upload the local test case to the cloud platform. Based on the first test case and the terminal device, a closed-loop test is performed to determine the test results.

2. The method according to claim 1, characterized in that, The step of performing closed-loop testing based on the first test case and the terminal device, and determining the test results, specifically includes: A test instruction is generated based on the first test case, and the test instruction is sent to the test device so that the test device can test the terminal device according to the test instruction and collect test data. The test data is compared and analyzed with the test instructions to determine the test result.

3. The method according to claim 1, characterized in that, The step of generating a second test case and its corresponding target version number based on the edit license flag and the edit node information specifically includes: The test case is edited according to the editing permission mark, the target test device type and initial version number are determined, and the target test plan is determined by matching the target test device type with the preset test plan library. Based on the analysis of the test cases and the target test plan, the target test item information and the target test state sequence are determined; and based on the equipment test requirements and the target test state sequence, the target test model is determined. The second test case is generated based on the target test model, the target test item information, the target test state sequence, and the target test plan. The initial version number is then updated based on the second test case to determine the target version number.

4. The method according to claim 3, characterized in that, The step of updating the initial version number based on the second test case to determine the target version number specifically includes: The second test case was analyzed to determine the changes in the state sequence, the changes in the test items, and the changes in the test plan. The initial version number is updated based on the changes in the state sequence, the changes in the test items, the changes in the test plan, and the preset update rules to determine the target version number.

5. The method according to claim 1, characterized in that, The method further includes: The cloud test case is updated based on the second test case and the target version number.

6. A synchronous testing system for distributed IoT terminals, characterized in that, The system includes a joint debugging warehouse and a cloud platform, wherein... The joint debugging repository is used to execute the method of any one of claims 1 to 5, generate a lock editing permission application, a second test case and a target version number, and send the lock editing permission application, the second test case and the target version number to the cloud platform; wherein, the joint debugging repository includes a plurality of terminal devices; The cloud platform is used to generate an editing flag based on the locked editing permission application, send the editing flag to the joint debugging repository, and update the cloud test case according to the second test case and the target version number.

7. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

Images