Automatic equipment software testing method and system

Abstract

The invention provides an automatic equipment software testing method and system. The automatic equipment software testing method comprises the following steps: acquiring a toolkit containing a hot pause parameter, an action mark and an associated action execution strategy; a test case containing test steps is called, action marks are added to the test steps, and expected values corresponding to the test steps are pre-configured in the test case; configuring a hot pause parameter of the test case, running the test case and obtaining a return value of the test step, when the return value does not accord with an expected value, judging that the test step has an error, and when the hot pause parameter is a first preset value, according to an action mark associated with the first preset value, determining that the test step has an action. And triggering the test case to enter hot pause according to an action execution strategy associated with the first preset value, and executing error checking and repairing logic. According to the method and the device, when the test steps of the test case have errors, the test case can be triggered to enter the hot pause and execute the error checking and repairing logic, so that the test steps with the errors are repaired.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to an automation equipment software testing method and an automation equipment software testing system. Background Art

[0002] Semiconductor equipment such as ATE (Automatic Test Equipment), WAT (Wafer Acceptance Test) or SEM (Scanning Electron Microscope, SEM) is an automated equipment used to measure or test chips (hereinafter referred to as "automated equipment"). The automated equipment has built-in programs with specific computer logic written in high-level languages ​​to form software that drives the hardware contained in the automated equipment or the actuators composed of hardware to perform specific actions. Software testing is required during the development process or software testing phase or after the software is introduced into the automated equipment to check for defects (i.e., bugs) or unreasonable logic in the software programming, which will cause errors (e.g., Errors) in the operation of the automated equipment, or to verify whether the functions contained in the software (i.e., source program) can be used normally.

[0003] Software testing methods in the prior art are usually based on pre-written test scripts (or "test cases"), and use the test scripts to test the software in the order in which the software is executed. When an error occurs in the software (for example, syntax error, logic error, environment variable configuration error, interface error, etc.), the error status of the software is recorded and the test script is exited. However, in the process of testing the test case based on the test script in the prior art, once it is detected that the software throws an error, the test case may crash and exit directly. Therefore, it is impossible to save the state of the test case corresponding to the error thrown and the progress of the test case execution when an error occurs in the test step in the test case, which causes great inconvenience to the developer in discovering and repairing the code. At the same time, since the progress of the test case execution cannot be saved, the test efficiency is greatly reduced and the full utilization of the test case cannot be guaranteed.

[0004] In view of this, it is necessary to improve the technical solutions such as the testing method for automated testing of software contained in automation equipment in the prior art to solve the above problems. Summary of the invention

[0005] The purpose of the present invention is to disclose an automated equipment software testing method and an automated equipment software testing system, and to solve the technical problems in the prior art of directly exiting the test when an error occurs in a test step during the testing of a test case, resulting in the inability to save the test process of the test case, greatly reducing the test efficiency and failing to ensure the full utilization of the test case.

[0006] To achieve one of the above purposes, the present invention provides an automated equipment software testing method, comprising:

[0007] Acquire a toolkit, the toolkit comprising thermal pause parameters with different preset values, action tags associated with the thermal pause parameters with different preset values, and associated action execution strategies;

[0008] Calling a test case including test steps and adding action tags to the test steps, wherein the test case is pre-configured with an expected value corresponding to each of the test steps;

[0009] Configure the hot pause parameter of the test case, run the test case and obtain the return value of the test step, compare the return value with the expected value, and when the return value does not match the expected value, determine that an error has occurred in the test step, and when the hot pause parameter is a first preset value, according to the action mark associated with the first preset value, trigger the test case to enter hot pause according to the action execution strategy associated with the first preset value, and execute error troubleshooting and repair logic to repair the test step where the error occurred, and according to the repair result of the test step where the error occurred, choose to continue executing the test case or terminate the test directly.

[0010] As a further improvement of the present invention, the action execution strategy further includes: directly terminating the test or ignoring the error and continuing to execute the test case;

[0011] The automation equipment software testing method also includes: when the return value does not match the expected value, it is determined that an error occurs in the test step, and when the hot pause parameter is a second preset value, according to the action mark associated with the second preset value, triggering the direct termination of the test or ignoring the error and continuing to execute the test case according to the action execution strategy associated with the second preset value, and the second preset value is different from the first preset value.

[0012] As a further improvement of the present invention, the execution error troubleshooting and repair logic includes:

[0013] Selecting a test step to be re-executed, obtaining a test step to be repaired according to the execution result of the test step to be re-executed, and executing error troubleshooting and repair logic on the test step to be repaired to repair the error of the test step;

[0014] Based on the execution result of the error troubleshooting and repairing logic, continue to execute the test case or terminate the test directly.

[0015] As a further improvement of the present invention, the executing error troubleshooting and repairing logic to repair the error of the test step includes:

[0016] According to the execution result of the selected test step to be repaired, modify the script of the test step to be repaired or modify the input parameter that triggers the test step to be repaired to output a return value to repair the test step where an error occurs. The script of the test step includes the parameters, variables or values ​​of the test step.

[0017] As a further improvement of the present invention, after modifying the script of the test step to be repaired or modifying the input parameter that triggers the test step to be repaired to output a return value to repair the test step where an error occurs, it also includes:

[0018] The test step to be re-executed is executed again, and when the return value returned by the test step to be re-executed is consistent with the expected value, it is determined that the repair of the test step in which the error occurred is completed.

[0019] As a further improvement of the present invention, the step of selecting a test step to be re-executed, obtaining a test step to be repaired according to an execution result of the test step to be re-executed, and executing error troubleshooting and repair logic on the test step to be repaired to repair the error of the test step includes:

[0020] Determine whether the error occurring in the test step is a critical error or a non-critical error. If it is a critical error, select the test step to be re-executed, and re-execute the test step to be re-executed, obtain the test step to be repaired according to the execution result, execute the error troubleshooting and repair logic for the test step to be repaired to repair the error of the test step, and further determine whether the error of the test step is repaired. If so, determine whether to continue testing the test step where the error occurs until the test of the test step is completed. If not, terminate the test directly;

[0021] If it is a non-critical error, determine whether to ignore the error of the test step. If so, ignore the error of the test step and continue to execute the test case; if not, terminate the test directly or select the test step to be re-executed. When selecting the test step to be re-executed, obtain the test step to be repaired according to the execution result of the test step to be re-executed, and execute error troubleshooting and repair logic on the test step to be repaired to repair the error of the test step.

[0022] As a further improvement of the present invention, the test case consists of a step set including at least one test step;

[0023] The adding action marks to the test steps includes: adding action marks to all test steps in the step set of the test case that belong to the same logical branch, or adding action marks to all test steps in the step set of the test case that belong to at least two adjacent logical branches, or adding action marks to all test steps in one or more step sets of the test case.

[0024] As a further improvement of the present invention, after repairing the test step in which the error occurs, it also includes:

[0025] The event of executing the error troubleshooting and repairing logic is saved to form a test report, and the test report is configured as a test interface embedded in a visual interface, so as to be output to the test interface and displayed after the test execution of the test case is completed.

[0026] As a further improvement of the present invention, the test interface is at least embedded to form a control interface, and the control interface forms a direct test termination control, and when the direct test termination control is triggered, the test is directly terminated.

[0027] As a further improvement of the present invention, the return value of the test step, the error information thrown by the test step entering hot pause, and the event of executing the error troubleshooting and repair logic are written into the test report.

[0028] Based on the same inventive concept, the present application also provides an automated equipment software testing system, including:

[0029] At least one processor, at least one memory, a bus and an I / O device; the processor, the memory and the I / O device communicate with each other via the bus; the memory stores program instructions executable by the processor, and the processor calls the program instructions to execute the steps of the automation equipment software testing method as described in any of the above inventions.

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

[0031] The automated equipment software testing method and automated equipment software testing system in the present application realize the preservation of the execution progress of the test case, ensure the full utilization of the test case, and improve the test efficiency, that is, the execution progress of the test case can be saved. When an error occurs in the test step of the test case, the test case is triggered to enter hot pause and execute the error troubleshooting and repair logic to repair the test step where the error occurs, thereby avoiding the loss of test progress caused by direct exit when an error occurs in the test step of the test case. After exiting, the test step where the error occurs cannot be repaired, and the subsequent test steps cannot be continued after the repair is completed, resulting in the inability to fully utilize the test case, and the technical effect of facilitating the accurate positioning and repair of the logical position of the test step where the error occurs in the test case is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is an overall flow chart of the automation equipment software testing method of the present invention;

[0033] Figure 2 An overall topology diagram of an automated device software testing method in one embodiment;

[0034] Figure 3 An overall topology diagram of an automated device software testing method in another embodiment;

[0035] Figure 4 1 is a topology diagram of test cases in some embodiments, where the dashed arrows represent the organizational relationship between the test steps contained in each logical level of the test case, and the solid arrows represent the jump relationship between the test steps contained in each logical level of the test case;

[0036] Figure 5 A detailed flow chart of an automated device software testing method in one embodiment;

[0037] Figure 6 A detailed flow chart of an automation equipment software testing method in another embodiment;

[0038] Figure 7 A diagram for selectively adding action markers to one or more test steps in the same logical hierarchy of a test case. Figure 7 and Figure 4 The dashed arrows in have the same meaning;

[0039] Figure 8 A schematic diagram for adding action tags locally and in batches for multiple test steps in a test case located at different and related logical levels. Figure 8 and Figure 4 The dashed arrows in have the same meaning;

[0040] Fig. 9A schematic diagram for globally adding action tags to all test steps contained in a test case. Fig. 9 and Figure 4 The dashed arrows in have the same meaning;

[0041] Fig.10 A schematic diagram of a test interface for forming a test report;

[0042] Fig.11 The output of adding action tags to the test steps passed in by the decorator is as follows Figures 8 to 10 Schematic diagrams of three output results of adding action tags are shown respectively;

[0043] Fig.12 This is a topological diagram of an automated equipment software testing system of the present invention. DETAILED DESCRIPTION

[0044] The present invention is described in detail below in conjunction with the various embodiments shown in the accompanying drawings, but it should be noted that these embodiments are not limitations of the present invention, and any equivalent transformations or substitutions in functions, methods, or structures made by ordinary technicians in the field based on these embodiments are all within the scope of protection of the present invention.

[0045] The object of the test performed by the automated equipment software testing method (hereinafter referred to as "software testing method" or "method") and the automated equipment software testing system (hereinafter referred to as "software testing system" or "system") disclosed in the present application may be source code and its logic (i.e., source program or Figure 2 The test case 20 is different from the source program (for example, Figure 2 The aforementioned method and system are used to perform automated testing on the software 10 to be tested using the test case 20, and are mainly intended to solve the technical problem that the software testing method in the prior art cannot save the error of the test case 20 during the test process due to the direct exit of the test when an error occurs in the test case 20 and the test steps contained therein, and thereby record the on-site status of the error to achieve the technical effect of "freezing the error site", so as to facilitate the subsequent discovery and repair of the defects of the test case 20, so as to maximize the use of the test script of the test case 20.

[0046] The software testing method and software testing system disclosed in each specific embodiment of the present application perform software testing by executing the test case 20 on the software 10 to be tested. For example, the test case 20 can be used to execute the software 10 to be tested to ensure that the function of the software 10 to be tested meets the specification, or to prove whether the code of the software 10 to be tested has errors and defects, so as to test the real software interface and software function of the source program running in N physical devices such as physical devices 1 to 1N (the parameter N is a positive integer greater than or equal to 1). Therefore, the software test is to test from the corresponding relationship between the input data (i.e., the expected value described below) and the output data (i.e., the return value described below), so as to determine whether the test case 20 or the test steps contained in the test case 20 have errors by comparing the return value with the expected value, thereby determining whether the software interface and software function of the software 10 to be tested meet the design requirements and functional requirements, for example, whether the software function is incorrect or missing, whether there is an interface error in the software interface, whether there is an error in database access, etc. Whether the interaction process between the simulation and the source program meets the design expectations and the functional defects or code defects or errors of the software under test 10 are discovered, the correctness and integrity of the source code of the software under test 10 are verified.

[0047] For example, the source program referred to in this application is regarded as software running in a physical device such as an automation device (for example, a semiconductor device). The software can be equivalent to Figure 3 The software to be tested 10 to software to be tested 10N are respectively deployed in the physical devices 1 to 1N. The physical devices 1 to 1N include but are not limited to semiconductor devices such as ATE equipment, SEM equipment, WAT equipment, wafer film thickness measurement equipment, and wafer defect detection equipment. Alternatively, the source program can also be run on other industry-specific automation equipment (for example, PCB board detection equipment, mechanical parts manufacturing automation equipment, etc.). It should be noted that the high-level computer languages ​​used in the development of the software to be tested 10 (i.e., the source program) are not limited to C, C++, C#, Python, JAVA, etc.

[0048] The request to execute the test case 20 to test the software under test 10~10N is initiated from a test device that is logically independent of the computer device included in the automation device. The test device includes a host 30 and a UI (visual interface) 50, and the UI50 can have a conversation with the user (USER). The UI50 can be embedded in the host 30. The physical devices 10~10N can be regarded as local computer devices or part of the local computer device. The test case 20 has the same execution logic as the software under test 10, or the test case 20 is used to simulate the execution logic of some functions and / or operation interfaces of the software under test 10, or the test case 20 is used to execute the code of the functions and / or operation interfaces of the software under test 10 to jointly evaluate whether the software interface and software functions of the software under test 10 meet the design requirements and functional requirements through multiple test cases 20.

[0049] Optional, reference Figure 2 As shown, the test interface 100 can be embedded and run in a local computer device that is directly connected to a local physical device based on a local network (local area network) or a cable (for example, an optical fiber). The aforementioned local computer device runs the software testing system 1000 to perform black box testing on the test case 20 in the local computer device by executing the software testing method in this application. In this technical scenario, the test case 20, the host 30 and the UI50 are all deployed in the local computer device, and the test interface 100 is embedded in the UI50. The user (USER) can directly operate the software testing system 1000 and execute the software testing method through the UI50. A two-way session is established between the test case 20 and the host 30 through a two-way arrow 21, the UI50 sets the API interface 51, the host 30 sets the API interface 32, and the API interface 51 and the API interface 32 establish a two-way session. The test case 20 establishes a two-way session with the software to be tested 10 through the two-way arrow 22. All data, scripts, and information generated during the testing of the test case 20, such as the test case 20, the toolkit 40, and the test report, can be stored in the database (DB) 31 for later use and viewing. The local computer device is physically separated from the physical device 1.

[0050] Optional, reference Figure 3As shown, the local computer device deploying the software testing system 1000 can also establish a session with one or more entity devices through the network 60 through the two-way arrows 24 and 25, and the test interface 100 is embedded in the UI 50. Multiple entity devices communicate with the local computer device through the network 60. Even, the test case 20 can be deployed in multiple computer devices that are physically isolated and located in a different place with the same network topology architecture as mentioned above, so that the user (USER) can remotely execute the software testing method in this application on one or more test cases. The user (USER) can be understood as a tester, developer or end user who performs the test.

[0051] Ginseng Figure 1 and Figure 2 As shown, the automation equipment software testing method includes steps S1 to S3.

[0052] Step S1: Acquire a toolkit, wherein the toolkit includes thermal pause parameters with different preset values, action tags associated with the thermal pause parameters with different preset values, and associated action execution strategies.

[0053] The first preset value and the second preset value in the following are the different preset values ​​mentioned above. The hot pause parameters of the preset first preset value and the second preset value will execute different subsequent actions correspondingly when an error occurs in the test step, for example, triggering the test case to enter hot pause and execute error troubleshooting and repair logic, or directly terminating the test, or ignoring the error and continuing to execute the test case. Figure 2 and Figure 3 As shown, the toolkit 40 can be called, and customized selections can be made for the thermal pause parameters with different preset values, the action tags associated with the thermal pause parameters with different preset values, the associated action execution strategies, and the error troubleshooting and repair logic used by the thermal pause parameters with corresponding preset values ​​carried by the toolkit 40. The aforementioned thermal pause parameters with different preset values, the action tags associated with the thermal pause parameters with different preset values, the associated action execution strategies, and the error troubleshooting and repair logic used by the thermal pause parameters with corresponding preset values ​​can all be regarded as configuration information of the toolkit 40. The toolkit 40 can also be pre-configured with other configuration information for testing the test case 20, which will not be repeated here.

[0054] Step S2: calling a test case including test steps and adding action tags to the test steps, wherein the test case is pre-configured with an expected value corresponding to each of the test steps.

[0055] The test case 20 and the toolkit 40 are logically separated from each other, and the toolkit 40 is called by the test case 20. When multiple marked test steps contained in the test case 20 have errors, the hot pause parameters contained in the toolkit 40, the action tags associated with the hot pause parameters, and the associated action execution strategies are used to automatically perform corresponding subsequent operations after determining whether the test steps are correct. For example, the error troubleshooting and repair logic is executed to repair the test steps that have errors. Usually, the test case 20 is written in advance and exported from the database (DB31) of the local computer device in the form of database access and subsequent tests are performed. Alternatively, the tester may not export from the database and create the test case 20 in a field programming manner. In step S2, the test case 20 containing different test steps is called to execute the test steps to implement the test of the software 10 to 10N to be tested. When the test case 20 is called, the test steps contained in the test case 20 are added with action tags as needed. The action tags can represent a mark indicating which action execution strategy is executed when an error occurs in the test step.

[0056] In some embodiments, the execution error troubleshooting and repair logic in step S2 includes: selecting a test step to be re-executed, obtaining a test step to be repaired according to the execution result of the test step to be re-executed, and executing the error troubleshooting and repair logic on the test step to be repaired to repair the error of the test step, wherein the execution error troubleshooting and repair logic to repair the error of the test step includes: modifying the script of the test step to be repaired or modifying the input parameter that triggers the output return value of the test step to be repaired according to the execution result of the selected test step to be repaired, so as to repair the test step in which the error occurs. The error in some test steps is not due to the error in the code itself, but the error in the input parameter. Therefore, it is necessary to modify the script of the test step to be repaired or modify the input parameter that triggers the output return value of the test step to be repaired to repair the test step in which the error occurs. Finally, re-execute the test step to be re-executed, and when the return value returned by the test step to be re-executed matches the expected value, it is determined that the repair of the test step in which the error occurs is completed.

[0057] In some embodiments, the script of the test step includes the parameters, variables or values ​​of the test step. According to the execution result of the error troubleshooting and repairing logic, the test case continues to be executed or the test is directly terminated for the test step that has executed the error troubleshooting and repairing logic. It should be noted that in some test scenarios, the error in the test step is not caused by the writing error of the test script of the test step, nor is it caused by the input data error of the current test step with the error and other test steps associated with it, but is due to the error in the parameters, variables or values ​​of the test step, and this error is usually extremely minor. Therefore, in the process of performing error troubleshooting and repair, the error in the parameters, variables or values ​​of the test step can be repaired based on the error troubleshooting and repairing logic.

[0058] In some implementations, in step S2, a test step to be re-executed is selected, a test step to be repaired is obtained according to the execution result of the test step to be re-executed, and an error troubleshooting and repair logic is executed on the test step to be repaired to repair the error of the test step, including:

[0059] Determine whether the error occurring in the test step is a critical error or a non-critical error. If it is a critical error, select the test step to be re-executed, and re-execute the test step to be re-executed. According to the execution result, obtain the test step to be repaired, execute the error troubleshooting and repair logic for the test step to be repaired to repair the error of the test step, and further determine whether the error of the test step is repaired. If so, determine whether to continue testing the test step where the error occurred until the test step is completed. If not, terminate the test directly.

[0060] If it is a non-critical error, determine whether to ignore the error of the test step. If so, ignore the error of the test step and continue to execute the test case; if not, terminate the test directly or select the test step to be re-executed. When selecting the test step to be re-executed, obtain the test step to be repaired according to the execution result of the test step to be re-executed, and execute the error troubleshooting and repair logic on the test step to be repaired to repair the error of the test step.

[0061] Step S3, configure the hot pause parameter of the test case, run the test case and obtain the return value of the test step, compare the return value with the expected value, when the return value does not match the expected value, determine that the test step has an error, and when the hot pause parameter is a first preset value, according to the action mark associated with the first preset value, trigger the test case to enter hot pause according to the action execution strategy associated with the first preset value, and execute the error troubleshooting and repair logic to repair the test step where the error occurs, and according to the repair result of the test step where the error occurs, choose to continue to execute the test case or terminate the test directly. The action mark is associated with whether the hot pause parameter is the first preset value or the second preset value, and different subsequent actions are performed based on the first preset value and the second preset value. The first preset value and the second preset value are parameter values ​​and can be preset in the toolkit 40. At the same time, in some embodiments, the action execution strategy in the present application also includes: directly terminating the test or ignoring the error and continuing to execute the test case 20. Therefore, when the hot pause parameter is the first preset value and the current test step has an error, the test step and test case where the error occurs enter hot pause. When the hot pause parameter is the second preset value and an error occurs in the current test step, the test is selectively terminated directly or the error is ignored and the test case is continued to be executed. As for whether to directly terminate the test or continue to execute the test case, it can be selected by Figure 6 Step 411 and subsequent steps in the process are distinguished, and the specific process is described below.

[0062] For example, if the first preset value is set to 123 and the second preset value is set to 321, the parameter control method can be used to determine whether the test step and test case where the error occurs need to enter the hot pause. At this time, when the test step is tested, the hot pause parameter is further described by the first preset value and the second preset value. If the hot pause parameter used by the test step where the error occurs is the first preset value, the hot pause is directly entered, and the subsequent error troubleshooting and repair logic is executed, and according to the repair result of the test step where the error occurs, the test case is selected to continue to execute or directly terminate the test, so that the execution of the test case is not directly and completely exited, and the test case can still be continued to execute, and the test case can be maximized to improve the test efficiency; if the hot pause parameter used by the test step where the error occurs is the second preset value, it is not directly hot paused, and the direct termination of the test or the error is ignored and the test case is continued to execute. Therefore, through two different preset values ​​(i.e., the first preset value and the second preset value), it is further distinguished that when the test step has an error, it can be flexibly determined whether to actually enter the hot pause, so that the script of the test case can be maximized. If the preset value carried by the hot pause parameter included in the toolkit 40 is neither 123 nor 321, but the preset value is empty (None) or the preset value is 000, then even if an error occurs in the test step, there is no need to enter hot pause, and there is no need to perform subsequent error repair and verification operations after the error repair.

[0063] After repairing the test step where the error occurs, that is, after step S3 is executed, in some embodiments, the software testing method further includes: saving the event of executing the error troubleshooting and repairing logic to form a test report, and the test report is configured as a test interface 100 embedded in the visual interface, so as to be output to the test interface 100 and displayed after the test execution of the test case is completed. The correctness of the test step, the return value of the test step, the error information thrown by the test step entering the hot pause, and the event of executing the error troubleshooting and repairing logic are written into the test report.

[0064] In this solution, when an error occurs in the test steps of a test case, the test case can be triggered to enter a hot pause and execute error troubleshooting and repair logic to repair the test steps where the error occurs, and based on the repair results of the test steps where the error occurs, you can choose to continue executing the test case or directly terminate the test, thereby avoiding the problem of being unable to execute subsequent test steps of the test case due to direct exit when an error occurs in the test steps of the test case, that is, the problem of being unable to save the execution progress of the test case, and making it easy to accurately locate and repair the logical position of the test steps where the error occurs in the test case; in addition, you can also choose not to enter a hot pause when an error occurs in the test steps of the test case, which can adapt to more test scenarios and has greater flexibility. You can choose the execution method when an error occurs in the test steps according to different test scenarios to avoid all test cases using the same test strategy, which can improve test efficiency.

[0065] Ginseng Figure 5 As shown, a specific implementation of the software testing method is shown.

[0066] start.

[0067] Step 401: Load the toolkit 40 and call the test case.

[0068] Step 402: Add an action tag to the test step. Figure 7 As shown, adding action tags can be done by marking multiple test steps at the lowest level of the same logical level (i.e., the first type of selective marking), or marking multiple test steps at a higher level of the same logical level (i.e., the second type of selective marking), or marking multiple test steps at the highest level of the same logical level (i.e., the third type of selective marking). Of course, action tags can also be added separately to certain test steps that need to be focused on. Figure 8 As shown in FIG. 9 , action tags can be added by marking multiple test steps at multiple logical levels (i.e., local batch tagging). As shown in FIG. 9 , action tags can also be added to all test steps contained in the test case as a whole (i.e., global batch tagging). Figure 8 The objects targeted by the partial batch marking shown are not strictly required to belong to adjacent logical levels, as long as there is program running logic such as calling and being called between each test step based on the execution logic of the test case.

[0069] Then, a test process of cyclically testing all test steps included in the test case 20 is entered, that is, a Loop cycle. Steps 403 to 410 are cyclically executed to test all test steps included in the test case.

[0070] Step 403: configure the hot pause parameters of the test case, and test the test steps contained in the test case. Usually, the test is performed starting from the first test step of the execution logic contained in the test case 20.

[0071] Step 404: Determine whether an error occurs in the test step, and specifically determine whether the return value matches the expected value. If the return value matches the expected value, the test step is deemed correct and the process jumps to step 410. If the return value does not match the expected value, the test step is deemed to have an error and the process jumps to step 405.

[0072] Step 405: The test step has an error and is hot-paused. When the hot-pause parameter configured for the test case is the first preset value, the test step will enter hot-pause when an error occurs.

[0073] Step 406: Execute the error troubleshooting and repair logic to repair the test step where the error occurs.

[0074] Step 407: Determine whether the error of the test step has been repaired. If the error of the test step has been repaired, jump to step 409. If the error of the test step has not been repaired, jump to step 408. Among them, step 407 can be to execute the test step to be re-executed again. When the return value returned by the test step to be re-executed matches the expected value, the test step where the error occurs is repaired. It should be noted that steps 406 and 407 are optional steps. If the action execution strategy associated with the first preset value pre-configured for the test case and the test step does not need to repair the test step that enters the hot pause, or even if the error is repaired, there is no need to determine whether the error of the test step is repaired. The judgment logic, then steps 406 and 407 can be omitted, and step 409 is directly executed, and it is considered that the test step has been tested and the next test step is continued, or the test is directly terminated, that is, step 415 is executed. If the error in the test step is a critical error or the user considers it to be a critical error, the test can be automatically terminated directly, or in some embodiments, the user manually clicks Fig.10 The direct termination test control 243 is used to terminate the test directly.

[0076] Step 408: directly terminate the test. The purpose is to directly terminate the test when a critical error occurs or when the test steps for the error are not successfully repaired, so as to avoid damage to the test case.

[0077] Step 409: The test step is executed and the next test step is executed cyclically.

[0078] Step 410: When all the test steps included in the test case 20 are tested, the test case is deemed to be tested and a test report is generated. The test report includes the return values ​​generated by all the test steps during the test execution, the test steps that are tested correctly, the comparison results of the return values ​​and the expected values, the repair events and error repair results of the error-detecting and repairing logic for the test steps with errors, the events of modifying the scripts of the test steps to be repaired, the events of modifying the input parameters that trigger the output of the return values ​​of the test steps to be repaired, the test steps with hot pauses and their logical positions in the entire test case 20, so as to facilitate the user to check afterwards and accurately locate the logical positions of the test steps with errors, especially the test steps with critical errors, so as to facilitate the user to optimize and modify the scripts of the test case 20 in the later stage, so as to more easily and efficiently find the irrationality, programming errors and execution logic errors of the test case 20 in the code writing stage, so as to effectively "freeze" the error scene, thereby effectively avoiding the technical problems in the prior art that once the test case throws an error, the test case may crash and exit directly, and the state and cause of the test case corresponding to the error cannot be saved.

[0079] Finish.

[0080] In some embodiments, the software testing method further includes: when the return value does not match the expected value, it is determined that an error occurs in the test step, and when the hot pause parameter is a second preset value, according to the action tag associated with the second preset value, triggering the direct termination of the test or ignoring the error and continuing to execute the test case according to the action execution strategy associated with the second preset value, and the second preset value is different from the first preset value. Specifically, the first preset value and the second preset value are both preset values ​​and are stored in the toolkit 40, and the first preset value and the second preset value can set parameter values ​​by assignment statements or function definitions. At the same time, the first preset value and the second preset value can be parameter values ​​of the same type or parameter values ​​of different types, and can be assigned or defined arbitrarily. For example, the first preset value is "ab" and the second preset value is "ac", or the first preset value is "007" and the second preset value is "008", or the first preset value is "#7" and the second preset value is "%9", and so on.

[0081] Both the return value and the expected value can be data types or text types that can be recognized and read by the test software 20, and include numerical values ​​(for example, integers, floating point numbers, Boolean numbers, etc.), strings (sequences of characters used to represent text data), special symbols (for example, #, &, etc.), lists, dictionaries, sets, null values, variables, object descriptors, AISC codes, and even text or operation logic. This application does not provide detailed examples. The expected value is pre-configured, and the expected value can be configured in advance for each test step, or multiple test steps that are logically associated, or a set of steps (i.e., test objects). The expected value is set in advance by the testee when writing the test case 20, and the return value is any of the aforementioned test objects. A typical test object is to run a test step to test the software 10 to be tested, and the data (or text or a combination of data and text) output during the execution of the test. The process of testing the test case 20 is to set multiple detection points in the test case through assertions to determine whether the return value output when running to the detection point meets the expected value. When the test case executes to the assertion position, the corresponding assertion should be true. If the assertion is not true, the test case will terminate execution and throw an error message. The purpose of assertions is to ensure that errors can be found and fixed in time during the development process of the test case, thereby improving the quality and maintainability of the test case 20. As a typical example, the expected value can be set to a. If the return value is b, the test step is judged to be an error and "False" is output; if the return value is a, the test step is judged to be correct and "True" is output.

[0082] For example, the critical errors referred to in this application include: logical errors (e.g., conditional judgment errors, loop logic errors, etc.), errors that cause software crashes or malfunctions, as well as abnormal device temperature errors, excessive system resource (e.g., CPU and memory) usage, downtime, heartbeat interruption, communication interruption, device initialization failure, or device calibration failure. For critical errors, it is necessary to perform a hot pause and troubleshoot the error and repair the code corresponding to the error, and repairing the code corresponding to the error is an optional step. Therefore, re-attempting Figure 5 As shown, Figure 5 Steps 406 and 407 in the figure are dashed boxes and can be omitted. Therefore, when steps 406 and 407 are omitted, after step 405 is executed, if it is considered that an error has occurred and the test step of hot pause is entered and the user believes that the error that has occurred is a critical error, the direct test termination control 243 can still be manually triggered to terminate the test directly. At this time, the jump process indicated by the dashed arrow 415 can be directly jumped to step 409 after step 405 is executed.

[0083] For example, the non-critical errors referred to in this application include: interface errors (for example, incorrect control naming, unreasonable button position, incorrect label description, etc.), performance errors (for example, too long response time, etc.). For non-critical errors, a hot pause can be executed to troubleshoot errors and repair the code corresponding to the error, or a hot pause can not be executed to troubleshoot errors and repair the code corresponding to the error, and repairing the code corresponding to the test step where the non-critical error occurs is an optional step. The critical errors and non-critical errors defined in this application are not determined by the logical level of the test steps in the test case, so the main distinguishing factors for distinguishing critical errors from non-critical errors include: functional importance and the number of calls. Of course, users can also manually define the errors that occur in certain test steps as critical errors or non-critical errors.

[0084] Ginseng Figure 4 As shown, a test case is composed of a step set including at least one test step. Specifically, a test case may include test step 101, test step 102 and test step 103 whose logical architecture is located at the first layer. Test step 101 includes test step 1011 and test step 1012 whose logical architecture is located at the second layer. Test step 1011 includes test step 1011a, test step 1011b and test step 1011c whose logical architecture is located at the third layer. The running logic of the test software is to first execute test step 1011a, then jump to execute test step 1011b according to arrow S-1, and then jump to execute test step 1011c according to arrow S-2. When all test steps 1011a to 1011c are executed, it is considered that test step 1011 is executed, and then jump to execute test step 1012 according to arrow S-4. When test step 1012 is executed, it points to the first test step 101 located at the first layer according to arrow S-5, and thus it is considered that test step 101 is executed. Then, test step 102 and test step 103 are executed in sequence according to the execution order of arrow S-6 and arrow S7. Figure 4 The exemplary logic architecture can regard the test steps 1011a - 1011c as all the test steps of the same logic branch, and regard the test steps 1011a - 1011c as a step set.

[0085] Similarly, test steps 1011 to 1012 can be regarded as all test steps of the same logical branch, and test steps 1011 to 1012 can be regarded as a step set. In this scenario, test step 1011a is an associated step of test step 1011b. Test step 1011 is the upper layer test step of test steps 1011a to 1011c. Test step 1011 is the lower layer test step of test step 101. However, whether it is an associated step or a test step of the upper logical level or a test step of the lower logical level, it is only relative to the computer language architecture when the test case is created. The logical relationship described is the sequence of execution of the code or script, the calling relationship, or the nesting relationship, etc. Therefore, the step set in this application contains test steps of several layers of logical architecture, or the number of test steps located in the next layer contained in a certain level, which can be arbitrarily understood, and one or more test steps can be arbitrarily classified into a step set, or multiple test steps of different levels can be organized and understood as a step set.

[0086] From the perspective of code programming of the test case, step 1011 can also be regarded as the first test step to be executed in the entire logical branch including step 1011 and steps 1011a to 1011c. Therefore, the division basis of the so-called step set in this application needs to be specifically analyzed according to the programming logic of the test case, and the aforementioned multiple implementations disclosed in this application are only several typical examples, and do not specifically limit the inventive concept contained in this application.

[0087] In some embodiments, as a reasonable variation of the aforementioned specific implementation, adding action tags to test steps includes: adding action tags to all test steps in the same logical branch in the step set of the test case, or adding action tags to all test steps in at least two adjacent logical branches in the step set of the test case, or adding action tags to all test steps in one or more step sets of the test case. Through the aforementioned technical means, the marking strategy for adding action tags to test steps is more flexible and convenient. For the test scenario of some test steps that need to be tested intensively, action tags can be added only to some test steps, thereby reducing the number of operations for adding action tags to the test steps contained in the test case 20, thereby improving the test efficiency. The aforementioned addition of action tags to the test steps is completed by a decorator, and can be modified by the decorator when the test case 20 is created, or, after the test case 20 calls the toolkit 40, the action tags that have been modified by the decorator and added can be modified later. The decorator can add additional functionality to the functions or objects in the test case 20 without destroying the internal logical structure of the test case 20, and will not modify or destroy the code of the test case 20.

[0088] Ginseng Figures 7 to 9 As shown, adding action tags can be done by Figure 7 The logical architecture is partially marked in (hereinafter referred to as "Strategy 1"), and can include Figure 7 The three rectangular boxes in the figure correspond to the first to the third selective marking strategies. You can also use Figure 8 The marking strategy of local batch marking in the middle (hereinafter referred to as "Strategy 2"). You can also use Fig. 9 The global batch marking strategy (hereinafter referred to as "Strategy 3") should be understood as follows: Figures 7 to 9 The test case in can be a complete test case, or a part of a complete test case and can be understood as a sub-test case, so that a complete test case is formed by combining multiple sub-test cases to complete the test of the test case. Strategy 1, Strategy 2 and Strategy 3 can all be regarded as configuration information, and the user can flexibly select Strategy 1, Strategy 2 or Strategy 3, so as to add action marks to multiple test steps that are considered to need to be tested in a focused manner or add action marks to multiple test steps that are logically related to each other, thereby further improving the test efficiency of the test case using the software testing method disclosed in this application and shortening the test cycle.

[0089] Ginseng Fig.11As shown, when no error occurs in test step 1011a but an error occurs in test step 1011b, test step 1011b transmits the error upward. At this time, there are three possibilities.

[0090] Box 61 shows the first scenario. At this time, an error occurs in test step 1011b, and it can be determined that test step 1011, which belongs to the same logic branch and is located at the previous layer, also has an error, and the error in test step 1011b is caused by test step 1011. Therefore, when executing the error troubleshooting and repairing logic to repair the error, it is necessary to repair the errors of test step 1011b and test step 1011 at the same time.

[0091] The second scenario is shown in box 62. At this time, an error occurs in test step 1011b, but the error in test step 1011b is not caused by test step 1011. Therefore, when executing the error troubleshooting and repairing logic to repair the error, only the error in test step 1011b needs to be repaired.

[0092] The third scenario is shown in frame 63. At this time, a critical error occurs in test step 1011b, so no error repair is performed, but an event of directly terminating the test is automatically performed directly, and the subsequent test process of test step 1011c is immediately exited.

[0093] Ginseng Fig.10 As shown, the test interface 100 is at least embedded to form a control interface 203, and the control interface 203 forms a direct test termination control 243. When the direct test termination control 243 is triggered, the test is terminated directly.

[0094] Specifically, Fig.10 The test interface 100 is embedded to form a log content interface 200, a test operation interface and a control interface 203. The test report can be dynamically displayed in the log content interface 200 in an online manner. Optionally, the test report can also be exported in XML, TXT, and LOG file formats after all the test steps contained in the test case 20 are tested, and can be saved as a readable file for subsequent reading by the tester. As an optional method, the test report can also be in a picture format, and the picture format includes but is not limited to JPG, PNG, GIF format, etc. The test operation interface 201 can dynamically display the call toolkit 40 call event, expected value, return value, comparison result of expected value and return value, historical operation, setting process of hot pause parameters, execution of error troubleshooting and repair logic to repair the repair event of the test step that has been sent out incorrectly, and other test intermediate information. All information dynamically displayed in the test operation interface 201 will be saved in the log content interface 200, and the test report can be output during the test process or after the test is completed.

[0095] Specifically, the control interface 203 in the present application is embedded with the following controls (i.e., Commands) whose computer logic can be triggered by a cursor or instruction: a test start control 213, an ignore and continue control 223, a throw exception error control 233, and a direct test termination control 243. Click the test start control 213 to start testing a specific test case. The triggerable visual controls such as the ignore and continue control 223 and the throw exception error control 233 are manually clicked in the scenario where an error is found during the test and needs to be repaired and no action mark has been added to the test step before, to respectively trigger the aforementioned call event and repair event executed based on the action execution strategy during the automatic execution of the test process.

[0096] More specifically, manually clicking the ignore and continue control 223 occurs when the return value of the test step does not match the expected value and the test step where the error occurs is not determined in advance whether to be ignored, so that the test step where the error occurs is manually ignored and the test of the next test step associated with its logic is continued. Manually clicking the throw exception control 233 occurs when the return value does not match the expected value, but the tester believes that it is not necessary to terminate the test directly, nor to execute the error troubleshooting and repair logic to repair the test step where the error occurs, but only needs to record the error. It is usually applicable to scenarios where there are code defects in the test case 20 but do not affect the overall logic of the test case 20, for example, non-standard code or code format errors. Generally, these code defects will not affect the reliable operation of the test case 20, nor are they functional defects. If all the test steps are set with expected values ​​and compared with the return values, the above-mentioned automated testing process will affect the test efficiency of the test case to a certain extent. Therefore, the present application improves the test efficiency of the test case by introducing the ignore and continue control 223, and is conducive to discovering code defects, and repairing minor errors by retrieving the test report after the test is completed.

[0097] As a further extension of the aforementioned specific implementation, the test interface 100 is embedded in a client (not shown) that is logically independent of the test case 20, and the client is embedded in a toolkit import interface for importing the toolkit 40, and a toolkit editing interface (not shown) for editing the toolkit 40. The test interface 100 is embedded in an online editing interface, so that instructions for manually inputting parameters, variables or values ​​of the test steps can be manually input in the online editing interface, or input parameters of the test step output return value can be manually modified in the online editing interface. The aforementioned online editing interface and toolkit editing interface can be embedded in Fig.10 In the test interface 100.

[0098] It should be noted that the aforementioned detection points are set in advance artificially, and are tested by testing the detection points that need to be tested in focus, and in particular, in order to accurately and efficiently find critical errors, so as to avoid damage to the automation equipment and test cases caused by the critical errors not being discovered in time and the test being terminated in time. Since the detection points are set in advance artificially, there are situations where the detection points are negligently omitted to be set. Therefore, the software testing method disclosed in the present application creatively introduces a direct termination test control 243, so that the tester can manually monitor the test running interface 201, and manually terminate the test points that are omitted from setting when critical errors occur, by clicking the direct termination test control 243, and directly terminate the test with a more flexible strategy.

[0099] Therefore, based on the software testing method disclosed in the above specific implementation, the present application also discloses another optional implementation of the software testing method, specifically referring to Figure 6 shown.

[0100] Figure 6 Relative to Figure 5 The main difference is that there are differences in the Loop cycle, as follows.

[0101] After step 405 is completed, step 411 needs to be executed first to determine whether the error in the test step is a critical error or a non-critical error. If it is a critical error (ie, Y), jump to step 412, if it is a non-critical error (ie, N), jump to step 413.

[0102] Step 412, select the test step to be re-executed, and obtain the test step to be repaired according to the execution result of the test step to be re-executed. It should be noted that even if the error in a certain test step is a critical error, there is also a test step in which the code logic itself is correct, and the reason for the critical error is that the associated test step with the test step in which the critical error occurs is an error. At this time, the associated test step (different from the current test step in which the critical error occurs) needs to be repaired based on the error troubleshooting and repair logic after entering the hot pause state due to the error. Therefore, when a critical error occurs in a test step, it is necessary to select the test step to be re-executed and the subsequent operation to ensure that the pre-test step is correct, and thereby reduce the probability of the error in the test step being misjudged as a critical error. In addition, it should be noted that after step 405 is executed, since the test step in which the error occurs may not be repaired, step 415 can also be directly executed, that is, the test is directly terminated.

[0103] Step 406: Execute error troubleshooting and repair logic on the test step to be repaired to repair the error in the test step.

[0104] Step 407: Determine whether the error of the test step has been repaired, wherein step 407 may be to execute the test step to be re-executed again, and when the return value returned by the test step to be re-executed is consistent with the expected value, the test step where the error occurred has been repaired. If it has been repaired, jump to step 409, if it has not been repaired, jump to step 408.

[0105] Step 408: directly terminate the test, in order to avoid damage to the test case or the system when an error occurring in the test step cannot be repaired.

[0106] Step 409: The test step is executed and the next test step is executed cyclically.

[0107] As a logical branch of step 402, when the error occurring in the test step is a non-critical error, the execution jumps to step 413.

[0108] Step 413, determine whether to ignore the error of the test step, if so, jump to step 417, if not, jump to step 416. Through the two judgment logics of step 411 and step 412, non-critical errors are further subdivided into two cases, thereby avoiding the problem of incorrectly distinguishing non-critical errors based only on the action execution strategy associated with the hot pause parameter of the pre-configured second preset value, preventing users from missing the definition of critical errors, further improving the efficiency of discovering and repairing critical errors, and preventing non-critical errors from being mistakenly identified as critical errors and directly terminating the test, thereby improving the utilization and coverage of the test case code, improving the precision of the test of the code contained in the test case (i.e., the test script), and improving the test efficiency.

[0109] Step 416: When non-critical errors cannot be ignored, the user can manually trigger the direct test termination control 243 in the control interface 203 to directly terminate the currently running test step and jump to step 408 along arrow 4161, or select the test step to be re-executed and jump upward along arrow 4162 to execute step 406. For the test steps that were previously missed due to critical errors and that the user believes need to terminate the test directly, jump to step 408; for the test steps that are indeed non-critical errors and do not need to terminate the test directly, jump to step 409.

[0110] Step 417: Ignore the error of the test step and continue to execute the test case, and after the current test step is completed, jump to step 410.

[0111] Step 410: When all test steps included in the test case 20 are tested, the test case is deemed to be tested and a test report is generated.

[0112] Finish.

[0113] In summary, through the software testing method disclosed by the aforementioned multiple specific embodiments, the hot pause parameters of different preset values ​​configured in the pre-configured toolkit 40, the action tags associated with the hot pause parameters of different preset values, and the associated action execution strategies, and then adding action tags to the test steps, by comparing whether the return value is the same as the expected value, automatic testing without human intervention is achieved according to different preset values ​​(for example, the first preset value and the second preset value). In particular, the test steps that are considered to be more important can be focused on in advance, and the test steps where errors occur can be put into a hot pause state to save and record the on-site status of the errors, so as to achieve the technical effect of "freezing the error site", so as to facilitate the subsequent discovery and repair of defects in the test case 20, so as to maximize the use of the test script of the test case 20. At the same time, since the logical position and reference relationship of each test step or a step set including one or more test steps in the entire test case 20 are predetermined, any event in which an error occurs in any test step or step set and a hot pause is performed, or an event in which the test is repaired or the error is ignored and the test is continued to be executed will be saved in the test report, and the test report is visually embedded in the test interface 100. Therefore, the user or tester can monitor the test execution process and results of each test step and the entire test case 20 in real time on the screen, and can actively pause a test step when it is considered that manual intervention is required, or when a critical error is not defined in advance and the test needs to be terminated directly, the direct test termination control 243 can be triggered manually online to directly terminate the test step currently being executed.

[0114] Similarly, based on the software testing method disclosed in the above specific implementation manner, Fig.12As shown, the present application also discloses an automated equipment software testing system 1000. The software testing system 1000 includes: at least one processor 1, at least one memory 2, a bus 4 and an I / O device 3. The processor 1, the memory 2 and the I / O device 3 communicate with each other through the bus 4. The memory 2 stores program instructions that can be executed by the processor 1, and the processor 1 calls the program instructions to execute the steps of the automated equipment software testing method disclosed in any specific implementation. The specific implementation method and process of the automated equipment software testing method relied on in this embodiment refer to the above-mentioned embodiment, and will not be repeated here. In this embodiment, if the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product or a hardware product. Therefore, the aforementioned automated equipment software testing system 1000 can also be encapsulated as a whole in an electronic device (not shown). The electronic device includes a mobile hard disk or a flash memory device, etc.

[0115] It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and it is intended that all variations falling within the meaning and scope of the equivalent elements of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

[0116] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

Claims

1. A method for testing software for automated equipment, characterized in that: include: Acquire a toolkit, the toolkit comprising thermal pause parameters with different preset values, action tags associated with the thermal pause parameters with different preset values, and associated action execution strategies; Calling a test case including test steps and adding action tags to the test steps, wherein the test case is pre-configured with an expected value corresponding to each of the test steps; Configure the hot pause parameter of the test case, run the test case and obtain the return value of the test step, compare the return value with the expected value, and when the return value does not match the expected value, determine that an error has occurred in the test step, and when the hot pause parameter is a first preset value, according to the action mark associated with the first preset value, trigger the test case to enter hot pause according to the action execution strategy associated with the first preset value, and execute error troubleshooting and repair logic to repair the test step where the error occurred, and according to the repair result of the test step where the error occurred, choose to continue executing the test case or terminate the test directly.

2. The automation equipment software testing method according to claim 1, characterized in that: The action execution strategy also includes: directly terminating the test or ignoring the error and continuing to execute the test case; The automation equipment software testing method also includes: when the return value does not match the expected value, it is determined that an error occurs in the test step, and when the hot pause parameter is a second preset value, according to the action mark associated with the second preset value, triggering the direct termination of the test or ignoring the error and continuing to execute the test case according to the action execution strategy associated with the second preset value, and the second preset value is different from the first preset value.

3. The automation equipment software testing method according to claim 1, characterized in that: The execution error troubleshooting and repair logic includes: Selecting a test step to be re-executed, obtaining a test step to be repaired according to the execution result of the test step to be re-executed, and executing error troubleshooting and repair logic on the test step to be repaired to repair the error of the test step; Based on the execution result of the error troubleshooting and repairing logic, continue to execute the test case or terminate the test directly.

4. The automation equipment software testing method according to claim 3, characterized in that: The executing error troubleshooting and repairing logic to repair the error of the test step includes: According to the execution result of the selected test step to be repaired, modify the script of the test step to be repaired or modify the input parameter that triggers the test step to be repaired to output a return value to repair the test step where an error occurs. The script of the test step includes the parameters, variables or values ​​of the test step.

5. The automation equipment software testing method according to claim 4, characterized in that: After modifying the script of the test step to be repaired or modifying the input parameter that triggers the test step to be repaired to output a return value to repair the test step where an error occurs, the method further includes: The test step to be re-executed is executed again, and when the return value returned by the test step to be re-executed is consistent with the expected value, it is determined that the repair of the test step in which the error occurred is completed.

6. The automation equipment software testing method according to claim 3, characterized in that: The step of selecting a test step to be re-executed, obtaining a test step to be repaired according to an execution result of the test step to be re-executed, and executing error troubleshooting and repair logic on the test step to be repaired to repair an error in the test step includes: Determine whether the error occurring in the test step is a critical error or a non-critical error. If it is a critical error, select the test step to be re-executed, and re-execute the test step to be re-executed, obtain the test step to be repaired according to the execution result, execute the error troubleshooting and repair logic for the test step to be repaired to repair the error of the test step, and further determine whether the error of the test step is repaired. If so, determine whether to continue testing the test step where the error occurs until the test of the test step is completed. If not, terminate the test directly; If it is a non-critical error, determine whether to ignore the error of the test step. If so, ignore the error of the test step and continue to execute the test case; if not, terminate the test directly or select the test step to be re-executed. When selecting the test step to be re-executed, obtain the test step to be repaired according to the execution result of the test step to be re-executed, and execute error troubleshooting and repair logic on the test step to be repaired to repair the error of the test step.

7. The automation equipment software testing method according to claim 1, characterized in that: The test case consists of a step set including at least one test step; The adding action marks to the test steps includes: adding action marks to all test steps in the step set of the test case that belong to the same logical branch, or adding action marks to all test steps in the step set of the test case that belong to at least two adjacent logical branches, or adding action marks to all test steps in one or more step sets of the test case.

8. The automation equipment software testing method according to any one of claims 1 to 7, characterized in that: After fixing the test step where the error occurred, also include: The event of executing the error troubleshooting and repairing logic is saved to form a test report, and the test report is configured as a test interface embedded in a visual interface, so as to be output to the test interface and displayed after the test execution of the test case is completed.

9. The automation equipment software testing method according to claim 8, characterized in that: The test interface is at least embedded to form a control interface, and the control interface forms a direct test termination control. When the direct test termination control is triggered, the test is directly terminated.

10. The automation equipment software testing method according to claim 8, characterized in that: The return value of the test step, the error information thrown by the test step entering hot pause, and the event of executing the error troubleshooting and repair logic are written into the test report. 11.Automation equipment software testing system, characterized in that: include: at least one processor, at least one memory, a bus, and I / O devices; The processor, memory and I / O device communicate with each other via the bus; The memory stores program instructions that can be executed by the processor, and the processor can execute the steps of the automation equipment software testing method as claimed in any one of claims 1 to 10 by calling the program instructions.

Images