Large-scale wireless network automatic test system and method

Abstract

The invention relates to a large-scale wireless network automatic test system and method, the system comprises a test tool, a tested device, a business cloud and a mechanical arm, the test tool and the tested device are respectively in communication connection with the business cloud and the mechanical arm, the test tool is used for determining a control instruction according to a pre-configured test case, and the control instruction is sent to the tested device. Controlling the tested equipment through a transparent transmission interface or a mechanical arm of the business cloud based on a control instruction, wherein the control instruction is an instruction irrelevant to a protocol; and the test tool is also used for acquiring a device state returned by the tested device in response to the control instruction through the service cloud, judging whether the device state is consistent with the control instruction, if so, executing the next test case until all test cases are executed, and outputting a test report.

Description

A large-scale wireless network automated testing system and method Technical Field

[0001] This application relates to the field of automated testing, and in particular to a large-scale wireless network automated testing system and method. Background Technology

[0002] With the rapid development of the smart home industry, product iteration is accelerating, and application scenarios and device types are growing exponentially. This presents a severe challenge to testing work, with extremely complex testing scenarios and highly interconnected testing processes.

[0003] Traditional testing systems typically rely on manual testing or preliminary automated testing, which has significant technical shortcomings. (1) In the test preparation phase, environment setup is time-consuming and non-reusable. Especially in scenarios involving multiple devices, testers are required to manually perform physical connections, network configurations, and initial state settings. This is not only cumbersome but also makes it difficult to ensure the consistency of the environment, greatly affecting the initial progress of the test. (2) In the test execution phase, it is highly dependent on manual work and has prominent efficiency bottlenecks. In manual testing mode, testers need to strictly follow the test cases step by step, observe and record the results, and the massive regression testing requirements make the test cycle long. Existing automated frameworks have high professional requirements for script writers, and product updates may require adaptation modifications to a large number of scripts, resulting in low efficiency. (3) In the problem diagnosis phase, cross-layer localization is difficult and the debugging loop is lengthy. Testers cannot directly determine whether the root cause of the problem lies in the test script logic, the underlying interface adaptation, the device firmware defect, or the instability of the test environment itself, which greatly prolongs the test cycle.

[0004] Therefore, existing technologies suffer from long testing cycles. Summary of the Invention

[0005] This application provides a large-scale wireless network automated testing system and method to at least solve the problem of long testing cycles in related technologies.

[0006] In a first aspect, embodiments of this application provide a large-scale wireless network automated testing system. The system includes a testing tool, a device under test (DUT), a service cloud, and a robotic arm. The testing tool and the DUT are communicatively connected to the service cloud and the robotic arm, respectively. The testing tool is used to determine control commands based on pre-configured test cases, and control the DUT through the transparent transmission interface of the service cloud or the robotic arm based on the control commands. The control commands are protocol-independent commands. The testing tool is also used to obtain the device status returned by the DUT in response to the control commands through the service cloud, determine whether the device status is consistent with the control commands, and if so, execute the next test case until all test cases are executed and output a test report.

[0007] In one embodiment, the testing tool is used to send a protocol-independent first control command to the device under test through the transparent transmission interface of the service cloud; the service cloud is used to receive a first device status returned by the device under test in response to the first control command; the testing tool is used to obtain the first device status from the service cloud, determine whether the first device status is consistent with the first control command, and if so, execute the next test case until all test cases are executed and output a test report.

[0008] In one embodiment, the testing tool is used to send a protocol-independent second control command to the robotic arm, so that the robotic arm can control the device under test according to the second control command; the service cloud is used to receive a second device status returned by the device under test in response to the control of the robotic arm; the testing tool is used to obtain the second device status from the service cloud, determine whether the second device status is consistent with the second control command, and if so, execute the next test case until all test cases are executed and output a test report.

[0009] In one embodiment, the system further includes a business app, which is used to obtain a user account and authorization code, and the account and authorization code are used to log in to the testing tool; the business app is communicatively connected to the device under test, and the business app is also used to control the device under test and obtain the control string of the device under test according to the logs of the business app; the robotic arm is used to control the device under test under user control, and obtain the reporting string of the device under test according to the logs of the business app, and the control string and the reporting string are used to configure the test cases.

[0010] In one embodiment, the control instruction is configured to have all communication protocol-dependent fields, headers, and encapsulation formats stripped away, and the control instruction is a purely business-oriented string sequence.

[0011] Secondly, embodiments of this application provide a method for automated testing of large-scale wireless networks. The method is applied to a large-scale wireless network automated testing system as described in the first aspect. The system includes a testing tool, a device under test (DUT), a service cloud, and a robotic arm. The testing tool and DUT are communicatively connected to the service cloud and the robotic arm, respectively. The method includes: determining control instructions using the testing tool based on pre-configured test cases; controlling the DUT through a transparent interface of the service cloud or the robotic arm based on the control instructions; the control instructions being protocol-independent instructions; obtaining the device status returned by the DUT in response to the control instructions through the service cloud; determining whether the device status is consistent with the control instructions using the testing tool; if so, executing the next test case until all test cases are executed, and outputting a test report.

[0012] In one embodiment, the device under test (DUT) is controlled via a transparent interface of the service cloud based on the control command. The service cloud is used to obtain the device status returned by the DUT in response to the control command. The testing tool is used to determine whether the device status is consistent with the control command. This includes: sending a protocol-independent first control command to the service cloud via the testing tool; sending the first control command to the DUT via the transparent interface of the service cloud; receiving the first device status returned by the DUT in response to the first control command via the service cloud; obtaining the first device status from the service cloud via the testing tool; and determining whether the first device status is consistent with the first control command.

[0013] In one embodiment, the device under test (DUT) is controlled by the robotic arm based on the control command, and the device status returned by the DUT in response to the control command is obtained through the service cloud. The device status is then determined by the testing tool to be consistent with the control command. This includes: sending a protocol-independent second control command to the robotic arm through the testing tool, so that the robotic arm can control the DUT according to the second control command; receiving the second device status returned by the DUT in response to the robotic arm control through the service cloud; obtaining the second device status from the service cloud through the testing tool; and determining whether the second device status is consistent with the second control command.

[0014] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a large-scale wireless network automated testing system as described in the first aspect above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a large-scale wireless network automated testing system as described in the first aspect above.

[0016] The large-scale wireless network automated testing system and method provided in this application have at least the following technical effects.

[0017] This application decouples test cases from the underlying device protocol through protocol-independent control commands. Test cases can be written without concern for the final transmission and parsing protocol. The same set of test cases can be applied to devices supporting the same business function but using different communication protocols without modification, exhibiting high versatility and maintainability. Furthermore, since the business channel provides a transparent command interface decoupled from specific protocols, test script writing no longer requires developers to have knowledge of the underlying protocols, lowering the technical threshold for testing tasks and improving script development efficiency and quality. Moreover, by isolating business logic and device control logic, this application allows for rapid localization of problems to the business logic layer or the device control layer when tests fail, effectively shortening the testing cycle.

[0018] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and constitute a part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: FIG1 is a structural block diagram of a large-scale wireless network automated testing system according to an embodiment of this application; FIG2 is a timing diagram of a device controlled by control commands according to an exemplary embodiment; FIG3 is a timing diagram of a device controlled by a robotic arm simulating physical operations according to an exemplary embodiment; FIG4 is a flowchart of a large-scale wireless network automated testing method according to an embodiment of this application; FIG5 is a structural schematic diagram of an electronic device provided by an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0021] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0022] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0023] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0024] Against the backdrop of the rapid development of the smart home industry, the pace of product iteration continues to accelerate, and the number of application scenarios and device types is growing exponentially, which poses a severe challenge to testing and seriously restricts the speed of product launch and innovation.

[0025] The main contradictions in the current testing process are reflected in the following aspects: (1) In the test preparation stage, the environment setup is time-consuming and non-reusable. Each round of testing, especially in scenarios involving multi-device linkage, requires testers to manually perform physical connections, network configurations, and initial state settings. Not only is the operation cumbersome, but it is also difficult to ensure the consistency of the environment. Any slight difference may introduce deviations in the test results, leading to unreliable test conclusions or the need to repeat the test due to environmental issues, which greatly affects the initial progress of the test. (2) In the test execution stage, it is highly dependent on manual labor and has prominent efficiency bottlenecks. In the manual testing mode, testers need to strictly follow the test cases to operate, observe, and record the results step by step. For complex scenarios (such as the "away from home" mode triggering multiple device linkage), a single execution takes several minutes, while the massive regression testing requirements make the complete test cycle take several days or even weeks. Under the existing automation framework, its "script-interface" layered model introduces significant collaboration overhead. Script writers must deeply understand the control protocols and interface call details of the underlying devices, which is itself a cumbersome and error-prone process. Any product update or protocol change may require adaptation modifications to a large number of scripts, and the maintenance cost of automated scripts offsets the efficiency improvement they should bring. (3) In the problem diagnosis phase, cross-layer localization is difficult and the debugging loop is lengthy. When automated test cases fail, troubleshooting is difficult. Test executors cannot directly determine whether the root cause of the problem lies in the test script logic, the underlying interface adaptation, the device firmware defect, or the instability of the test environment itself. This forces multiple roles, such as script developers, interface library developers, and test executors, into inefficient cross-functional communication in order to locate the root cause. For simple functional failures, the diagnosis and repair loop may far exceed the test execution time, greatly extending the test cycle.

[0026] Therefore, existing technologies, due to their inherently cumbersome processes and strong coupling between various stages, prolong the entire cycle from test preparation to execution and problem diagnosis. This not only fails to meet the market demands of rapid iteration in smart home products but also results in a significant waste of human resources.

[0027] Based on the above, this application provides a large-scale wireless network automated testing system and method.

[0028] In a first aspect, embodiments of this application provide a large-scale wireless network automated testing system. Figure 1 is a structural block diagram of a large-scale wireless network automated testing system according to an embodiment of this application. As shown in Figure 1, the system includes a testing tool 10, a device under test 20, a service cloud 30, and a robotic arm 40. The testing tool 10 and the device under test 20 are respectively connected to the service cloud 30 and the robotic arm 40 for communication.

[0029] Optionally, the testing tool 10 is communicatively connected to the robotic arm 40 and the device under test (DUT) 20 in sequence, and also to the business cloud 30 and the DUT 20 in sequence. The testing tool 10 is used by the user to edit test cases, automatically execute test cases, judge test results, and output test reports. In the example of this application, the DUT 20 is a smart home device that requires functional testing. The business cloud 30 is used to forward control commands from the testing tool 10 to the DUT 20 and receive feedback results from the DUT 20. The robotic arm 40 is used to operate the DUT 20 when physical operation is required.

[0030] Test tool 10 is used to determine control commands based on pre-configured test cases. Based on the control commands, the device under test is controlled through the transparent transmission interface of business cloud 30 or robotic arm 40. The control commands are protocol-independent commands.

[0031] Optionally, before testing, the tester configures test cases on the test tool 10. After the tester starts the test process, the test tool 10 sends control commands to the test device 20 through the transparent transmission interface of the cloud service 30. When the device under test 20 requires physical operation, the test tool 10 controls the test device through the robotic arm 40.

[0032] Among them, the business channel between the test tool 10 and the device under test 20 reuses the communication channel of the smart home device interacting with the platform in actual business operation. The business channel provides a transparent command interface decoupled from specific protocols. The business channel can also be implemented in the following ways: (1) Channel based on message middleware, implemented based on message queue or event bus. The test script, as a producer, publishes standardized instructions to a specific topic, while the agent or cloud service deployed on the device side, as a consumer, subscribes to the topic and is responsible for the final conversion and distribution of the protocol. This asynchronous mode further decouples the test execution end and the device control end. (2) Channel implementation based on Remote Procedure Call Framework (RPC), specifically manifested as a remote procedure call framework. The test script calls a remote function as if calling a local function. The underlying RPC framework hides all network communication and protocol conversion details.

[0033] Among them, control instructions are protocol-independent instruction data. Specifically, control instructions can be (1) a protocol-independent, purely business-oriented string sequence; (2) a protocol-independent key-value pair combination; (3) a standardized object model, that is, a predefined, standardized data object with fixed attributes and methods. The upper-level script operates on this object, and the serializer in the business channel converts the object into protocol data; (4) a markup language. Control instructions can be represented as a simplified XML or JSON fragment. This semi-structured data maintains human readability, is easy for machines to parse, and is also protocol-independent.

[0034] This approach decouples test cases from the underlying device protocols, eliminating the need to worry about the specific protocol stack used for transmission and parsing when writing test cases. The same set of test cases can be applied to devices supporting the same business function but using different communication protocols (e.g., a light controlled by Wi-Fi and a light controlled by Zigbee), significantly improving the reusability of test assets and reducing maintenance costs associated with protocol iterations or changes. It offers high versatility and maintainability. Furthermore, because the business channel provides a transparent command interface decoupled from specific protocols, test script writing no longer requires developers to have knowledge of the underlying protocols, lowering the technical barrier to testing. The testing team can focus more on the design of the business scenarios and the test cases themselves, improving script development efficiency and quality. Moreover, the business channel interface is more stable than frequently changing device protocols. When device protocols or firmware are upgraded, only adaptation modifications are needed within the business channel, without affecting a large number of upper-layer test scripts, reducing the overall system maintenance cost.

[0035] In one example, the control command is configured to strip away all fields, headers, and encapsulation formats that are strongly related to the communication protocol, and the control command is a purely business-oriented string sequence.

[0036] Optionally, regarding the form of the control instructions described above, this application preferably uses protocol-independent, purely business-oriented string sequences. By stripping all fields, headers, and encapsulation formats strongly related to specific communication protocols (such as Wi-Fi, Zigbee, Bluetooth LE, etc.) from the instruction data, the control instructions are refined into a purely business-oriented string sequence. In this way, test cases are decoupled from the underlying device protocol, and the writing of test cases does not need to concern itself with the final protocol stack used for transmission and parsing. The same set of test cases can be applied to devices supporting the same business function but using different communication protocols without modification, improving the reusability of test assets and reducing maintenance costs caused by protocol iteration or changes.

[0037] The testing tool 10 is also used to obtain the device status returned by the device under test 20 in response to the control command through the business cloud 30, determine whether the device status is consistent with the control command, and if so, execute the next test case until all test cases are executed and output a test report.

[0038] Optionally, after the test tool 10 controls the test device 20 through the transparent transmission interface of the cloud service 30 or the robotic arm 40, the test device 20 will report the device status to the service cloud 30. The test tool 10 will then access the device status in the service cloud and determine whether the device status is consistent with the control command.

[0039] In one example, the system also includes a business app 50, which is used to obtain user accounts and authorization codes, and the accounts and authorization codes are used to log in to the test tool 10.

[0040] The business app 50 communicates with the device under test 20. The business app 50 is also used to control the device under test 20 and obtain the control string of the device under test 20 according to the log of the business app 50.

[0041] The robotic arm 40 is used to control the device under test 20 under user control and to obtain the reporting string of the device under test 20 according to the logs of the business app 50. The control string and the reporting string are used to configure test cases.

[0042] Optionally, the test business channel and smart home devices use the same communication channel to interact with the platform during actual business operation (i.e., non-test state). Before configuring test cases, testers configure the test environment and functions, log in to the business app, and obtain the user's account and authorization code from the logs. For cases where the device under test (DUT) 20 is controlled via control commands, testers control the device through the business app and obtain the device's control string from the app's operation logs. For cases where the DUT 20 is controlled by a robotic arm 40 simulating physical operations, testers manually control the device and obtain the DUT 20's reporting string from the business app's operation logs. The test tool 10 is logged in using the account and authorization code. The corresponding strings and inspection content are then filled into the test cases to configure them.

[0043] In this way, a unified, protocol-decoupled, transparent command interface is provided for upper-layer automated test scripts. By reusing the communication channels used by smart home devices to interact with the platform in actual business operations, test traffic and real business traffic share the same mature and stable communication infrastructure. Because this channel has been continuously verified and optimized in the production environment, its stability and reliability are far superior to dedicated interfaces temporarily set up for testing and not fully verified. Furthermore, the test environment and the real business environment are unified at the underlying communication level, ensuring that test results accurately reflect the product's performance in actual applications and avoiding deviations introduced by differences between the test and real environments.

[0044] In one example, test tool 10 is used to send a protocol-independent first control command to device under test 20 through the transparent interface of business cloud 30.

[0045] The business cloud 30 is used to receive the first device status returned by the device under test 20 in response to the first control command.

[0046] Test tool 10 is used to obtain the status of the first device from the business cloud 30, determine whether the status of the first device is consistent with the first control command, and if so, execute the next test case until all test cases are executed and output a test report.

[0047] Optionally, for the case where the device under test 20 is controlled by control commands, Figure 2 is a timing diagram of controlling the device by control commands according to an exemplary embodiment. As shown in Figure 2, the control flow is as follows: Step S1, the tester configures the test environment, adds the device to the home, and configures the corresponding device functions.

[0048] Step S2: The tester logs into the business app 50 and obtains the account and authorization code for the device to join the family through the logs of the business app.

[0049] In step S3, the tester controls the device under test 20 through the business app 50. The device under test 20 returns the control result to the business app 50, and the control string of the device is obtained through the log of the business app.

[0050] In step S4, the tester exports logs from business app 50 to obtain the corresponding data. This data includes the family's account information, authorization code, and control strings.

[0051] Step S5: The tester logs into the testing tool 10 using their family account and authorization.

[0052] Step S6: The tester configures the test cases, fills in the corresponding strings and inspection content into the test cases, and returns the configuration results.

[0053] Step S7: Start the testing process.

[0054] In step S8, the test tool 10 sends the control command to the device under test 20 through the transparent transmission interface of the business cloud, and the device under test 20 returns the control result to the test tool 10.

[0055] Step S9: The device under test 20 reports its latest status to the business cloud 30.

[0056] In step S10, the test tool 10 accesses the business cloud 30 to obtain the current status of the device and determines whether the current status of the device is consistent with the instruction string sent to the device.

[0057] Step S11: Begin executing the next test case until all test cases have been executed.

[0058] Step S12: The tester queries and exports the test report.

[0059] In this way, the business logic is separated, that is, the business logic and the device control logic are isolated. When the test fails, the problem can be quickly located in the business logic layer or the device control layer, avoiding the lengthy troubleshooting process across roles, shortening the fault diagnosis path, and thus effectively compressing the test cycle.

[0060] In one example, the test tool 10 is used to send a protocol-independent second control command to the robotic arm 40, so that the robotic arm 40 can control the device under test 20 according to the second control command.

[0061] The business cloud 30 is used to receive the second device status returned by the device under test 20 in response to the control of the robotic arm 40.

[0062] Test tool 10 is used to obtain the status of the second device from the business cloud 30, determine whether the status of the second device is consistent with the second control command, and if so, execute the next test case until all test cases are executed and output a test report.

[0063] Optionally, for the case where the device under test 20 is controlled by simulating physical operation through the robotic arm 40, Figure 3 is a timing diagram of controlling the device by simulating physical operation through the robotic arm according to an exemplary embodiment. As shown in Figure 3, the control flow is as follows: Step S1, the tester configures the test environment, adds the device to the home, and configures the corresponding device functions.

[0064] Step S2: The tester logs into the business app 50 and obtains the account and authorization code for the device to join the family through the logs of the business app.

[0065] In step S3, the tester manually controls the robotic arm to control the device and obtains the device's reported string from the logs of the business app.

[0066] In step S4, the tester exports logs from business app 50 to obtain the corresponding data. This data includes the family's account number, authorization code, and reporting string, among other things.

[0067] Step S5: The tester logs into the testing tool 10 using their family account and authorization.

[0068] Step S6: The tester configures the test cases, fills in the corresponding strings and inspection content into the test cases, and returns the configuration results.

[0069] Step S7: Start the testing process.

[0070] In step S8, the testing tool 10 sends control commands to the robotic arm 40, the robotic arm 40 controls the device under test 20 according to the control commands, and the device under test 20 returns the control results to the testing tool 10.

[0071] Step S9: The device under test 20 reports its latest status to the business cloud 30.

[0072] In step S10, the test tool 10 accesses the business cloud 30 to obtain the current status of the device and determines whether the current status of the device is consistent with the instruction string sent to the device.

[0073] Step S11: Begin executing the next test case until all test cases have been executed.

[0074] Step S12: The tester queries and exports the test report.

[0075] In this way, the device control logic is separated, that is, the business logic and device control logic are isolated. When the test fails, the problem can be quickly located in the business logic layer or the device control layer, avoiding the lengthy troubleshooting process across roles, shortening the fault diagnosis path, and thus effectively compressing the test cycle.

[0076] In summary, this application decouples test cases from the underlying device protocol through protocol-independent control commands. Test case writing does not require concern about the final transmission and parsing protocol. The same set of test cases can be applied to devices supporting the same business function but using different communication protocols without modification, exhibiting high versatility and maintainability. Furthermore, since the business channel provides a transparent command interface decoupled from specific protocols, test script writing no longer requires developers to have knowledge of the underlying protocols, lowering the technical threshold for testing tasks and improving script development efficiency and quality. In addition, by reusing the communication channels used by smart home devices to interact with the platform in actual business operations, test traffic and real business traffic share the same mature and stable communication infrastructure, ensuring that test results accurately reflect the product's performance in real-world applications and avoiding deviations introduced by differences between the test and real environments. Moreover, by isolating business logic and device control logic, this application can quickly pinpoint the problem to the business logic layer or the device control layer when tests fail, effectively shortening the testing cycle.

[0077] Secondly, embodiments of this application provide a method for automated testing of large-scale wireless networks. The method is applied to a large-scale wireless network automated testing system as described in the first aspect. The system includes a testing tool, a device under test (DUT), a service cloud, and a robotic arm. Both the testing tool and the DUT are communicatively connected to the service cloud and the robotic arm, respectively. Figure 4 is a flowchart illustrating a method for automated testing of large-scale wireless networks according to an embodiment of this application. As shown in Figure 4, the method includes: step S101, determining control commands through the testing tool based on pre-configured test cases, and controlling the DUT through the transparent transmission interface of the service cloud or the robotic arm based on the control commands. The control commands are protocol-independent commands.

[0078] Step S102: Obtain the device status returned by the device under test in response to the control command through the business cloud, and use the test tool to determine whether the device status is consistent with the control command. If so, execute the next test case until all test cases are executed and output the test report.

[0079] In one example, the device under test is controlled through the transparent transmission interface of the business cloud based on control commands. The device status returned by the device under test in response to the control commands is obtained through the business cloud. The device status is determined by the test tool to determine whether it is consistent with the control commands. This includes: step S201, sending a protocol-independent first control command to the business cloud through the test tool, and sending the first control command to the device under test through the transparent transmission interface of the business cloud.

[0080] Step S202: Receive the first device status returned by the device under test in response to the first control command via the service cloud.

[0081] Step S203: Obtain the status of the first device from the business cloud using a testing tool, and determine whether the status of the first device is consistent with the first control command.

[0082] In one example, the device under test is controlled by a robotic arm based on control commands, and the device status returned by the device under test in response to the control commands is obtained through the business cloud. The device status is then determined by a test tool to determine whether it is consistent with the control commands. This includes step S301, where a protocol-independent second control command is sent to the robotic arm through the test tool so that the robotic arm can control the device under test according to the second control command.

[0083] Step S302: Receive the second device status returned by the robotic arm control in response to the device under test via the business cloud.

[0084] Step S303: Obtain the status of the second device from the business cloud using a testing tool, and determine whether the status of the second device is consistent with the second control command.

[0085] In one example, the system also includes a business app that communicates with the device under test.

[0086] The user account and authorization code are obtained through the business app. The account and authorization code are used to log in to the testing tool.

[0087] The device under test is controlled through the business app, and the control string of the device under test is obtained from the logs of the business app.

[0088] Users control the device under test through a robotic arm and obtain the reporting string from the logs of the business app. The control string and the reporting string are used to configure test cases.

[0089] In one example, the control command is configured to strip away all fields, headers, and encapsulation formats that are strongly related to the communication protocol, and the control command is a purely business-oriented string sequence.

[0090] In summary, this application decouples test cases from the underlying device protocol through protocol-independent control commands. Test case writing does not require concern about the final transmission and parsing protocol. The same set of test cases can be applied to devices supporting the same business function but using different communication protocols without modification, exhibiting high versatility and maintainability. Furthermore, since the business channel provides a transparent command interface decoupled from specific protocols, test script writing no longer requires developers to have knowledge of the underlying protocols, lowering the technical threshold for testing tasks and improving script development efficiency and quality. In addition, by reusing the communication channels used by smart home devices to interact with the platform in actual business operations, test traffic and real business traffic share the same mature and stable communication infrastructure, ensuring that test results accurately reflect the product's performance in real-world applications and avoiding deviations introduced by differences between the test and real environments. Moreover, by isolating business logic and device control logic, this application can quickly pinpoint the problem to the business logic layer or the device control layer when tests fail, effectively shortening the testing cycle.

[0091] Thirdly, embodiments of this application provide an electronic device, and Figure 5 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the large-scale wireless network automated testing system provided in the first aspect. The electronic device 60 shown in Figure 5 is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0092] Electronic device 60 may be in the form of a general-purpose computing device, such as a server device. Components of electronic device 60 may include, but are not limited to: at least one processor 61, at least one memory 62, and a bus 63 connecting different system components (including memory 62 and processor 61).

[0093] Bus 63 includes a data bus, an address bus, and a control bus.

[0094] The memory 62 may include volatile memory, such as random access memory (RAM) 621 and / or cache memory 622, and may further include read-only memory (ROM) 623.

[0095] The memory 62 may also include a program / utility 625 having a set (at least one) of program modules 624, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0096] The processor 61 executes various functional applications and data processing by running computer programs stored in the memory 62, such as the large-scale wireless network automated testing system provided in the first aspect of this application.

[0097] Electronic device 60 can also communicate with one or more external devices 64 (e.g., keyboard, pointing device, etc.). This communication can be performed via input / output (I / O) interface 65. Furthermore, the model-generated electronic device 60 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public network, such as the Internet) via network adapter 66. As shown, network adapter 66 communicates with other modules of the model-generated electronic device 60 via bus 63. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the model-generated electronic device 60, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems.

[0098] It should be noted that although several units / modules or sub-units / modules of the electronic device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0099] Fourthly, embodiments of this application provide a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the large-scale wireless network automated testing system provided in the first aspect.

[0100] The readable storage medium may be more specifically adopted, including but not limited to: portable disk, hard disk, random access memory, read-only memory, erasable programmable read-only memory, optical storage device, magnetic storage device, or any suitable combination thereof.

[0101] In a possible implementation, the present invention can also be implemented as a program product comprising program code, which, when the program product is run on a terminal device, is used to cause the terminal device to execute a large-scale wireless network automated testing system provided in the first aspect.

[0102] The program code for executing the present invention can be written in any combination of one or more programming languages. The program code can be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on a remote device.

[0103] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0104] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A large-scale wireless network automated testing system, characterized in that, The system includes a testing tool, a device under test (DUT), a service cloud, and a robotic arm. The testing tool and DUT are communicatively connected to the service cloud and robotic arm, respectively. The testing tool determines control commands based on pre-configured test cases and controls the DUT through the service cloud's transparent interface or the robotic arm based on these control commands. These control commands are protocol-independent. The testing tool also obtains the device status returned by the DUT in response to the control commands through the service cloud, determines whether the device status is consistent with the control commands, and if so, executes the next test case until all test cases are executed, and outputs a test report.

2. The large-scale wireless network automated testing system according to claim 1, characterized in that, The testing tool is used to send a protocol-independent first control command to the device under test through the transparent transmission interface of the service cloud; the service cloud is used to receive the first device status returned by the device under test in response to the first control command; the testing tool is used to obtain the first device status from the service cloud, determine whether the first device status is consistent with the first control command, and if so, execute the next test case until all test cases are executed and output a test report.

3. The large-scale wireless network automated testing system according to claim 1, characterized in that, The testing tool is used to send a protocol-independent second control command to the robotic arm, so that the robotic arm can control the device under test according to the second control command; the service cloud is used to receive the second device status returned by the device under test in response to the control of the robotic arm; the testing tool is used to obtain the second device status from the service cloud, determine whether the second device status is consistent with the second control command, and if so, execute the next test case until all test cases are executed and output a test report.

4. A large-scale wireless network automated testing system according to claim 2 or 3, characterized in that, The system also includes a business app, which is used to obtain a user account and authorization code, and the account and authorization code are used to log in to the testing tool; the business app is communicatively connected to the device under test, and the business app is also used to control the device under test and obtain the control string of the device under test according to the logs of the business app; the robotic arm is used to control the device under test under user control, and obtains the reporting string of the device under test according to the logs of the business app, and the control string and the reporting string are used to configure the test cases.

5. The large-scale wireless network automated testing system according to claim 1, characterized in that, The control command is configured to strip away all fields, headers, and encapsulation formats that are strongly related to the communication protocol, and the control command is a purely business-oriented string sequence.

6. A method for automated testing of large-scale wireless networks, characterized in that, The method is applied to a large-scale wireless network automated testing system according to any one of claims 1-5. The system includes a testing tool, a device under test (DUT), a service cloud, and a robotic arm. The testing tool and the DUT are respectively communicatively connected to the service cloud and the robotic arm. The method includes: determining control instructions through the testing tool based on pre-configured test cases; controlling the DUT through the transparent transmission interface of the service cloud or the robotic arm based on the control instructions; the control instructions being protocol-independent instructions; obtaining the device status returned by the DUT in response to the control instructions through the service cloud; determining whether the device status is consistent with the control instructions through the testing tool; if so, executing the next test case until all test cases are executed and outputting a test report.

7. The automated testing method for large-scale wireless networks according to claim 6, characterized in that, Based on the control command, the device under test is controlled through the transparent transmission interface of the service cloud. The device status returned by the device under test in response to the control command is obtained through the service cloud. The test tool determines whether the device status is consistent with the control command. This includes: sending a protocol-independent first control command to the service cloud through the test tool; sending the first control command to the device under test through the transparent transmission interface of the service cloud; receiving the first device status returned by the device under test in response to the first control command through the service cloud; obtaining the first device status from the service cloud through the test tool; and determining whether the first device status is consistent with the first control command.

8. The automated testing method for large-scale wireless networks according to claim 6, characterized in that, Based on the control command, the robotic arm controls the device under test (DUT). The service cloud is used to obtain the device status returned by the DUT in response to the control command. The testing tool is used to determine whether the device status is consistent with the control command. This includes: sending a protocol-independent second control command to the robotic arm via the testing tool, so that the robotic arm can control the DUT according to the second control command; receiving the second device status returned by the DUT in response to the robotic arm control via the service cloud; obtaining the second device status from the service cloud via the testing tool; and determining whether the second device status is consistent with the second control command.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements a large-scale wireless network automated testing system as described in any one of claims 1 to 5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements a large-scale wireless network automated testing system as described in any one of claims 1 to 5.

Images