Test framework, test method and terminal of end tool for hot-line work robot

Abstract

The invention relates to the field of automatic testing, and discloses a testing framework, a testing method and a terminal of an end tool for a hot-line work robot. The framework comprises the steps that a dependency environment is set by installing a project dependency package, the project dependency package comprises Pywinauto, Pytest and Pyyaml, and secondary packaging is carried out on the Pywinauto under a root directory; the basic function module comprises a created path acquisition module used for processing and acquiring a project root path and acquiring a configuration file, a test case reading and writing module used for realizing a reading and writing function of a test case, and a log recording module used for recording and inputting key information in a test execution process into a log file; the test case executor is used for controlling the test case to execute the operation of starting and closing the corresponding application program before and after the test case is executed; and the running file is used for running the basic function module and the test case executor in the dependency environment and carrying out test operation of the end tool for the hot-line work robot. The testing process is automatic, and the testing efficiency is greatly improved.

Description

Technical Field

[0001] The present invention relates to the field of automated testing, and in particular to a testing framework, a testing method and a terminal for an end tool of a live working robot. Background Art

[0002] With the continuous development of the live working robot industry, many traditional manual live working methods have been gradually replaced by live working robots. The live working robots required for each live working process are different. There are more than 10 types of live working robots on the market. With the continuous development of the live working robot industry and technology, the types and demand for live working robots are bound to surge in the future. Under this background, the previous manual testing can no longer meet the required testing tasks, and due to the differences in testers, manual testing is usually highly subjective. Therefore, how to ensure the improvement of live working robot testing efficiency and testing quality has become a difficult problem that needs to be solved urgently at this stage.

[0003] At present, the testing of live working robots mainly relies on manual testing, which is to send control commands by operating the live working robot control software and check the feedback status of the live working control software to test whether the functions of the live working robot are normal. However, the testing process is still cumbersome, monotonous and repetitive, and the cost is increasing day by day, and the testing efficiency is constantly decreasing. Summary of the invention

[0004] In order to solve the problem of reduced testing efficiency, the present application provides a testing framework, a testing method and a terminal for an end tool of a live working robot.

[0005] In a first aspect, the present application provides a test framework for an end-tool for a live working robot, including: a dependency environment, a basic function module, a test case executor, and a running file;

[0006] The dependency environment is set by installing the project dependency package, wherein the project dependency package includes: Pywinauto, Pytest and Pyyaml, and the Pywinauto is repackaged in the root directory;

[0007] The basic function module includes a creation path acquisition module, which is responsible for processing and obtaining the project root path and configuration file, a test case reading and writing module, which is used to implement the reading and writing functions of the test case, and a log recording module, which is used to record key information during the test execution process into a log file;

[0008] The test case executor is used to control the startup and shutdown operations of the corresponding application before and after the test case is executed;

[0009] The operation file is used to run the basic function module and the test case executor in the dependent environment to perform test operations on the end tool of the live working robot.

[0010] Furthermore, the test framework includes:

[0011] The test case executor includes a test tool class, in which a test tool method is defined, and a @pytest.mark.parametrize decorator is added before the test tool method to implement parameterized running of multiple test cases on the same test function.

[0012] Furthermore, the second packaging of the Pywinauto in the root directory includes:

[0013] Create a basic tool directory, in which the core dependent methods in Pywinauto are encapsulated in the Pywinauto control script, and the core dependent methods include: starting a specified application, connecting to a specified window of an application, listing all controls in an application, simulating mouse clicks, simulating keyboard input, obtaining control text values, setting a timeout wait time, and capturing screenshots.

[0014] In a second aspect, the present application provides a method for testing an end tool for a live working robot, which is applied to the live working robot testing framework, and the method comprises:

[0015] Determine the type of live-working robot to be tested;

[0016] Obtaining corresponding automated test cases according to the type of the live working robot, converting the test cases into a format, and reading the test cases after the format conversion;

[0017] The live-working robot is tested by running the converted test cases in multiple threads, and the test results are automatically generated after obtaining the data fed back by the live-working robot.

[0018] Furthermore, after the live working robot is tested by running the test case through multiple threads, the method further includes:

[0019] The status data of the live working robot at the current moment is read, and the status data is compared with the judgment standard data corresponding to the test case to determine whether the current test passes.

[0020] Further, the test case includes test case data and control name;

[0021] The step of converting the test case into a format and reading the test case after the format conversion includes:

[0022] Convert automated test cases in document format into test files in yaml format;

[0023] Read and verify whether the test file is written in accordance with a prescribed format to determine whether the test file is legal;

[0024] If it is legal, the test file is read, and a mapping relationship between the control name and the control element of the live working robot is established. Through the mapping relationship, the control name and the original name of the control element are replaced.

[0025] Furthermore, the test results include test data, test logs and visual test reports;

[0026] The step of automatically generating a test result after obtaining the data fed back by the live working robot includes:

[0027] After all test cases are executed, the test data fed back by the live working robot is obtained, and a test log is generated according to the obtained test data. The test data is visualized to generate a corresponding visual test report.

[0028] Furthermore, after the test results are automatically generated, the following steps are also included:

[0029] The test results are automatically sent to a configured email address in the form of email.

[0030] Furthermore, the testing of the live working robot by running the test case through multiple threads includes:

[0031] Create two threads, the first thread is used to execute the test case, and the second thread is used to synchronously detect and record status information during the test;

[0032] The status information includes motor status information, module status information, power information and execution step information. When an abnormality occurs during the test, it is reproduced according to the status information.

[0033] Furthermore, the test module also includes an output module;

[0034] The output module is used to obtain the test data fed back by the live working robot after all test cases are executed, generate a test log according to the obtained test data, and visualize the test data to generate a corresponding visual test report.

[0035] In a third aspect, the present application further provides a test terminal, comprising a processor and a memory, wherein the memory stores a computer program, and when the computer program runs on the processor, the test method for the end tool of a live working robot is executed.

[0036] The present invention discloses a test framework, test method and terminal for end tools of live working robots. The method comprises: determining the type of live working robot to be tested; obtaining corresponding automated test cases according to the type of live working robot, converting the test cases into formats, and reading the test cases after format conversion; configuring the live working robot as the corresponding item to be tested, testing the live working robot by running the test cases in multiple threads, and automatically generating test results after obtaining the data fed back by the live working robot. The test process is automated, the test efficiency is greatly increased, the test cost is reduced, and the test of live working tools is easier to control. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solution of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and should not be regarded as limiting the scope of protection of the present invention. In each of the drawings, similar components are numbered similarly.

[0038] Figure 1 A schematic flow chart of a method for testing an end tool for a live working robot according to an embodiment of the present application is shown;

[0039] Figure 2 A schematic diagram of an interactive process of testing a live working robot according to an embodiment of the present application is shown;

[0040] Figure 3 A schematic diagram of the structure of a live-working robot test framework according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0041] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments.

[0042] The components of the embodiments of the present invention generally described and shown in the drawings herein may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0043] Hereinafter, the terms "including", "having" and their cognates, which may be used in various embodiments of the present invention, are intended only to indicate specific features, numbers, steps, operations, elements, components or combinations of the foregoing items, and should not be understood as first excluding the existence of one or more other features, numbers, steps, operations, elements, components or combinations of the foregoing items or adding the possibility of one or more features, numbers, steps, operations, elements, components or combinations of the foregoing items.

[0044] Furthermore, the terms “first”, “second”, “third”, etc. are merely used for distinguishing descriptions and are not to be understood as indicating or implying relative importance.

[0045] Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meanings as those generally understood by those skilled in the art to which the various embodiments of the present invention belong. The terms (such as those defined in generally used dictionaries) will be interpreted as having the same meanings as the contextual meanings in the relevant technical field and will not be interpreted as having idealized meanings or overly formal meanings unless clearly defined in the various embodiments of the present invention.

[0046] The technical solution of this application provides a test method for the end tool of a live working robot. This application mainly determines the type of live working tool to determine the corresponding test case, and after converting the test case in the document format, uses the converted test case to perform automatic testing on the live working tool and automatically output the test results. The whole process is completely automatic, saving manpower and material resources and improving test efficiency.

[0047] Next, the technical solution of the present application is described with specific embodiments.

[0048] Example 1

[0049] like Figure 1 As shown, the test method of the end tool for the live working robot in this embodiment includes:

[0050] Step S100, determining the type of the live-line working robot to be tested.

[0051] The live-line working robot may be some equipment such as a live-line working robot or a mechanical arm, which are applied in various scenarios, and each live-line working robot basically has multiple functions. The test method of this embodiment is used to automatically test such a live-line working robot.

[0052] In this embodiment, a host computer is required to be connected to the live working robot, and the host computer runs an automated testing system to perform automated testing.

[0053] The testing method for the end tool of the live working robot of this embodiment can automatically complete all the testing processes starting from determining the live working robot to be tested. At the beginning, it is necessary to determine the type of the live working robot to be tested.

[0054] The main purpose of determining the type is to determine the type of live-line working robot and its test business logic, and then design the automated test scenario after clarifying the test requirements. Because there are many types of live-line working robots with many functions, the requirements for each test are also different, so the scope of the test needs to be determined at the beginning.

[0055] The type of live-working robot can be determined by parameters such as model, and the test requirements can be provided by the developer. These data can be stored in the live-working robot or on the cloud server through data quantification. Therefore, through some inspection operations, the type of live-working robot to be tested can be determined. From this, it can be determined how to test.

[0056] Further, such as Figure 2 As shown, it is an automated control test environment of the present embodiment, wherein the automated control system 100 is used to test the live working robot 300, and the live working robot software 200 is software running on a live working tool, and is used to control the live working robot. During the test, the corresponding functions are mainly implemented through the software for testing.

[0057] Step S200, obtaining corresponding automated test cases according to the type of the live working robot, converting the test cases into a format, and reading the test cases after the format conversion.

[0058] After determining the specific test method, you need to obtain automated test cases in a targeted manner. The automated test cases here are test cases recorded in a document format, which record the specific test steps, test case judgment criteria, control names, etc.

[0059] It is understandable that the test case computer program in the document format cannot be read, so it needs to be converted into a file in a predetermined format so that the test host computer can read the test case.

[0060] In this embodiment, the test case in the document format is converted into a test file in the yaml format, so that the test file can be directly read to perform subsequent test operations.

[0061] After conversion, the content of the test file will also be verified to ensure that the converted test file is a readable and legal file. For example, automated testing requires that the test file be written in the style of test case name, test function name, preconditions, automated test execution steps, and judgment criteria. It is necessary to detect whether the test file is written in the above manner.

[0062] The test process involves the control of some control elements of the live-line working robot, which are actually controlled by the control software of the live-line working robot. The software presents these control elements in the form of buttons to provide an interactive control interface. However, these control elements may be represented by IDs such as "Button1" in the underlying code instead of being represented by names, making it difficult for staff to determine the meaning of each control element.

[0063] As for the automated test program of this embodiment, the test for some functions needs to be carried out through the control of these control elements. Therefore, in the automated test case, there are control names corresponding to each control element, and the one-to-one correspondence can be established through a predetermined mapping relationship table. Therefore, after the format conversion, the control name will be replaced with the ID of the control element, so that in subsequent tests, the corresponding control can be directly tested and controlled according to the control name.

[0064] Reading the test case after format conversion means caching the test case in the automated testing system 100 so that the system can issue corresponding control operations according to the test file.

[0065] Step S300, configuring the live working robot as a corresponding item to be tested, testing the live working robot by running the test case in multiple threads, and automatically generating a test result after obtaining data fed back by the live working robot.

[0066] In order to start the test, the live working robot also needs to be configured so that the project to be tested has testable parameters before the test can be carried out. The configuration can be reconfigured through a configuration file, which includes the test project name, test environment, tester, controlled software, controlled tool, execution test case name, test report sending switch, enterprise WeChat webhook address, email sending address and other configuration information, so as to limit the source and destination of the test parameters and how the test results are stored during the entire test process.

[0067] After the configuration is completed, the live working robot can be tested. During the test, two threads are created. The first thread is used to execute the test, and the second thread is used to detect and record the status information during the test. The first thread and the second thread are executed synchronously.

[0068] The status information includes motor status information, module status information, power information and execution step information. When an abnormality occurs during the test, it is reproduced according to the status information.

[0069] It can be seen that when the test of this embodiment is carried out, there will be a second thread for monitoring to monitor the first thread, so that real-time test data can be obtained. The test data here is different from the data after the test is completed. The data obtained in real time is a status data in the middle of the test process, which is mainly used to reproduce the problem when a problem occurs in the test, so that the cause of the problem can be tracked.

[0070] The test results include test data, test logs and visual test reports. After all test cases are executed, the test data fed back by the live working robot is obtained, and a test log is generated based on the obtained test data. The test data is visualized to generate a corresponding visual test report.

[0071] It should be noted that after the test is carried out, the test results are obtained, and the status data of the live working robot at the current moment is read, and the status data is compared with the judgment standard data corresponding to the test case to determine whether the current test is passed. Thus, a simple pass judgment is obtained, and then combined with the test data, test log and visual test report, a very complete test analysis result can be obtained. In this embodiment, the analysis result is automatically generated. Therefore, for testers, work pressure is greatly reduced and work efficiency is increased.

[0072] In addition, during the configuration in step S200, basic information configurations such as corporate WeChat webhook and email sending address are also configured. It can be seen that after the test results are obtained, the test results will be automatically sent to the specified address, and the sending methods include email and WeChat message. In other words, after the test starts, the tester does not need to operate anymore, and knows that the test is completed when he receives the message.

[0073] In the test method of the end tool for the live working robot of this embodiment, by identifying the live working robot to be tested, determining what kind of test case file to use, and converting and verifying the format of the test case file, the test system can directly perform automated testing on the host computer. During the test, the test data will be known to be obtained to ensure that the problem can be reproduced. When the test is completed, the data will be automatically analyzed and judged, and visualized to obtain a complete test analysis result. From the beginning to the end of the test, it is fully automated, which greatly increases the test efficiency, reduces the test cost, reduces the burden on the testers, and reduces the errors that may occur during the test.

[0074] Example 2

[0075] like Figure 3 As shown, this embodiment also provides a test framework for an end tool for a live working robot, including: a dependent environment 100, a basic function module 120, a test case executor 130 and an operation file 140;

[0076] The dependency environment is set by installing the project dependency package, which includes: Pywinauto, Pytest and Pyyaml, and Pywinauto is repackaged in the root directory.

[0077] Among them, Pywinauto is a Python library for Windows GUI automation, which allows users to write scripts to automate the operations of Windows applications, such as clicking buttons, entering text, selecting menu items, etc. It is based on pywin32 and comtypes, providing a more advanced and easier-to-use interface.

[0078] Pytest is a unit testing framework for Python, similar to Python's own unittest testing framework, but simpler and more efficient to use. It is a very mature, full-featured testing framework that supports both simple unit testing and complex functional testing.

[0079] PyYAML is a Python library for parsing and generating YAML data. It provides a simple and easy-to-use interface for reading and writing YAML-formatted files, strings, or streams. With PyYAML, we can easily serialize Python objects into YAML-formatted strings, and deserialize YAML-formatted strings into Python objects.

[0080] Specifically, when performing secondary packaging, a basic tool directory will be created first. In the basic tool directory, the core dependent methods in Pywinauto are encapsulated in the Pywinauto control script. The core dependent methods include: starting a specified application, connecting to a specified window of an application, listing all controls in an application, simulating mouse clicks, simulating keyboard input, getting control text values, setting timeout wait time, and capturing screenshots.

[0081] The basic function modules include a path creation module, which is responsible for processing and obtaining the project root path and configuration file, a test case reading and writing module, which is used to implement the reading and writing functions of the test case, and a log recording module, which is used to record key information during the test execution process into a log file.

[0082] The specific encapsulated core API is shown in the following table:

[0083]

[0084]

[0085] It should be noted that what is shown in the table is only a possible implementation example, and the specific implementation method may be changed according to actual conditions.

[0086] The test case executor is used to control the startup and shutdown operations of the corresponding application before and after the test case is executed;

[0087] The operation file is used to run the basic function module and the test case executor in the dependent environment.

[0088] The test case executor includes a test tool class, in which a test tool method is defined, and a @pytest.mark.parametrize decorator is added before the test tool method to implement parameterized running of multiple test cases on the same test function.

[0089] @pytest.mark.parametrize is a decorator used in the pytest framework to implement test case parameterization. It allows multiple sets of parameters to be provided to a test function or test class, so that the test function or test class is executed with each set of parameters, and parameterized driven testing is implemented. In this way, the efficiency and coverage of the test can be greatly improved, especially when the test logic needs to handle multiple boundary conditions or input changes.

[0090] Developers can build a live working robot testing framework that can implement the method in Example 1 based on the above framework. First, set the Python project dependency environment, specifically: ① Use the Pycharm IDE development tool to create a Python project and set up the virtual environment venv; ② After the terminal switches to the virtual environment directory (venv), use the pip command to install project dependency packages such as Pywinauto, Pytest, and Pyyaml.

[0091] Then, the Pywinauto API was encapsulated for the second time. A base_utils directory was created in the project root directory. A new pywinauto_control.py file was created in this directory to encapsulate the core methods that depend on Pywinauto in the project, such as the connect_window method that needs to be connected to the controlled tool software through its pre-function before the test case is executed.

[0092] Then write the basic class, create a common_utils directory in the project root directory, and create a get_path_util.py file. This module is responsible for processing operations such as obtaining the project root path and obtaining configuration files, use case files and other dependent paths. It can be compatible with different paths according to different operating systems, which is convenient for the framework to be deployed in different operating systems. Create a get_yaml_util.py file. This module is responsible for implementing functions such as reading and writing test cases. Create a logging_util.py file to implement the logging function, and record key information during the test execution into the log file.

[0093] Continue to write the test case executor, create a script directory in the project root directory, create a new test_execute.py file, create a class test tool, define the test tool in the class, add the @pytest.mark.parametrize decorator before the method, and implement parameterized running of multiple test cases in the same test function after reading the test case. Create a new conftest.py file in the script directory, use the powerful fixture function provided by Pytest to manage the preparation and cleanup work before and after the test, create a new setup_environment function with the @pytest.fixture decorator to implement the application startup and shutdown work before and after the test case execution.

[0094] Finally, create a run.py file in the project root directory and call the pytest.main function in it to automatically collect directories starting with test* and test* functions under classes starting with Test*. After scanning and loading all test cases, it will call the pre-function in the conftest.py file in step 4, open the application, and after executing all test cases through the test case executor, close the application through the post-function.

[0095] The class starting with Test* above refers to the class whose name has the Test character prefix. * is a wildcard. This class has various functions with the test prefix. The directory starting with test* will store test-related data and programs.

[0096] The above-mentioned testing framework for the end tool of the live working robot can be used to execute the testing method for the end tool of the live working robot in Example 1 to test the end tool of the live working robot. The framework is mainly based on Pywinauto to realize the closed-loop process of the entire test, thereby increasing the automation capability of the test.

[0097] The present application also provides a test terminal, including a processor and a memory, wherein the memory stores a computer program, and when the computer program runs on the processor, the test method for the end tool of the live working robot is executed.

[0098] The present application also provides a readable storage medium storing a computer program, which executes the test method for the end tool of the live working robot when it is run on a processor. The method includes: determining the type of the live working robot to be tested; obtaining the corresponding automated test case according to the type of the live working robot, converting the test case into a format, and reading the converted test case; configuring the live working robot as the corresponding item to be tested, testing the live working robot by running the test case in multiple threads, and automatically generating the test result after obtaining the data fed back by the live working robot.

[0099] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and structure diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the structure diagram and / or the flow chart, and the combination of boxes in the structure diagram and / or the flow chart, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0100] In addition, the functional modules or units in the various embodiments of the present invention may be integrated together to form an independent part, or each module may exist independently, or two or more modules may be integrated to form an independent part.

[0101] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0102] The above description is only a specific implementation mode of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A test frame for an end tool of a live working robot, characterized in that: include: Dependency environment, basic functional modules, test case executors and running files; The dependency environment is set by installing the project dependency package, wherein the project dependency package includes: Pywinauto, Pytest and Pyyaml, and the Pywinauto is repackaged in the root directory; The basic function module includes a creation path acquisition module, which is responsible for processing and obtaining the project root path and configuration file, a test case reading and writing module, which is used to implement the reading and writing functions of the test case, and a log recording module, which is used to record key information during the test execution process into a log file; The test case executor is used to control the startup and shutdown operations of the corresponding application before and after the test case is executed; The operation file is used to run the basic function module and the test case executor in the dependent environment to perform test operations on the end tool of the live working robot.

2. The test frame of the end tool for live working robot according to claim 1, characterized in that: include: The test case executor includes a test tool class, in which a test tool method is defined, and a @pytest.mark.parametrize decorator is added before the test tool method to implement parameterized running of multiple test cases on the same test function.

3. The test frame of the end tool for live working robot according to claim 1, characterized in that: The second packaging of Pywinauto in the root directory includes: Create a basic tool directory, in which the core dependent methods in Pywinauto are encapsulated in the Pywinauto control script, and the core dependent methods include: starting a specified application, connecting to a specified window of an application, listing all controls in an application, simulating mouse clicks, simulating keyboard input, obtaining control text values, setting a timeout wait time, and capturing screenshots.

4. A method for testing an end tool for a live working robot, applied to a test frame for an end tool for a live working robot as claimed in any one of claims 1 to 3, characterized in that: The method comprises: Determine the type of live-working robot to be tested; Obtaining corresponding automated test cases according to the type of the live working robot, converting the test cases into a format, and reading the test cases after the format conversion; The test case executor is called through multi-threading to run the converted test case to test the live working robot, and the test result is automatically generated after obtaining the data fed back by the live working robot.

5. The method for testing the end tool for a live working robot according to claim 4, characterized in that: After calling the test case executor through multithreading to run the converted test case to test the live working robot, the method further includes: The status data of the live working robot at the current moment is read, and the status data is compared with the judgment standard data corresponding to the test case to determine whether the current test passes.

6. The method for testing the end tool for a live working robot according to claim 4, characterized in that: The test case includes test case data and control name; The step of converting the test case into a format and reading the test case after the format conversion includes: Convert automated test cases in document format into test files in yaml format; Read and verify whether the test file is written in accordance with a prescribed format to determine whether the test file is legal; If it is legal, the test file is read, and a mapping relationship between the control name and the control element of the live working robot is established. Through the mapping relationship, the control name and the original name of the control element are replaced.

7. The method for testing the end tool for a live working robot according to claim 4, characterized in that: The test results include test data, test logs and visual test reports; The step of automatically generating a test result after obtaining the data fed back by the live working robot includes: After all test cases are executed, the test data fed back by the live working robot is obtained, and a test log is generated according to the obtained test data. The test data is visualized to generate a corresponding visual test report.

8. The method for testing the end tool for a live working robot according to claim 4, characterized in that: After the test results are automatically generated, the following steps are also included: The test results are automatically sent to a configured email address in the form of email.

9. The method for testing the end tool for a live working robot according to claim 4, characterized in that: The step of testing the live working robot by running the test case through multiple threads includes: Create two threads, the first thread is used to execute the test case, and the second thread is used to synchronously detect and record status information during the test; The status information includes motor status information, module status information, power information and execution step information. When an abnormality occurs during the test, it is reproduced according to the status information.

10. A test terminal, characterized in that: The method comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is run on the processor, the method for testing the end tool for a live working robot according to any one of claims 4 to 9 is executed.

Images