Test method, device, test equipment and computer readable storage medium

Abstract

This application discloses a testing method, apparatus, testing equipment, and computer-readable storage medium. The method includes: acquiring a test script, the test script including multiple test items; the test script is determined based on test requirements and multiple preset functional modules, each of the multiple preset functional modules being used to test a corresponding function; responding to the selection operation of at least one target test item among the multiple test items, parsing the at least one target test item to obtain a parsing result; and executing the at least one target test item based on the parsing result. This improves the flexibility of testing.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and includes, but is not limited to, a testing method, apparatus, testing equipment, and computer-readable storage medium. Background Technology

[0002] Automated testing refers to the process of automatically executing pre-set test cases using software tools and scripts, and comparing actual results with expected results. Through rapid and consistent repetitive execution, automated testing can discover software defects earlier and more frequently, accelerating the feedback loop. Furthermore, automated testing improves the repeatability and accuracy of test execution, providing a stable and reliable guarantee for product quality.

[0003] However, in related technologies, automated testing only supports fixed testing processes, resulting in low testing flexibility and poor adaptability. Summary of the Invention

[0004] In view of this, the testing method, apparatus, testing equipment, and computer-readable storage medium provided in the embodiments of this application can improve the flexibility of testing. The testing method, apparatus, testing equipment, computer-readable storage medium, and computer program product provided in the embodiments of this application are implemented as follows: A first aspect of this application provides a testing method, the method comprising: Obtain a test script, which includes multiple test items; the test script is determined based on test requirements and multiple preset functional modules, each of the multiple preset functional modules being used to test the corresponding function; In response to the selection of at least one target test item among the plurality of test items, the at least one target test item is parsed to obtain the parsing result; Execute at least one target test item based on the parsing results.

[0005] The testing method provided in this application allows for the selection of at least one target test item from multiple test items based on a selection operation. This means obtaining at least one target test item that matches the selection operation. Then, this at least one target test item is parsed and executed. Since at least one target test item matches the selection operation, at least one target test item can be dynamically determined based on the selection operation, and then parsed and executed. Because different selection operations correspond to different at least one target test item, the flexibility of the testing is improved. Since different selection operations correspond to different testing requirements, targeted testing is achieved, thereby improving the adaptability of the testing.

[0006] A second aspect of the embodiments of this application also provides a testing apparatus, which includes: a first acquisition module, a parsing module, and an execution module; The first acquisition module is used to acquire a test script, which includes multiple test items. The test script is determined based on test requirements and multiple preset functional modules, and each preset functional module is used to test the corresponding function. The parsing module is used to parse the at least one target test item in response to the selection operation of the plurality of test items, and obtain the parsing result; An execution module is used to execute the at least one target test item based on the parsing results.

[0007] A third aspect of this application provides a testing device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the testing method of this application.

[0008] A fourth aspect of the embodiments of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the testing method provided in the embodiments of this application.

[0009] A fifth aspect of the embodiments of this application provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implement the testing method provided in the embodiments of this application. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the framework structure of the testing system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a testing method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating one of the execution target test items provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a method for determining a second target test item, as provided in an embodiment of this application. Figure 5 This is another flowchart illustrating the determination of the second target test item provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a method for determining a jump test item identifier, as provided in an embodiment of this application. Figure 7 This is another flowchart illustrating the execution of the target test item provided in an embodiment of this application; Figure 8 This is another flowchart illustrating the testing method provided in the embodiments of this application; Figure 9 This is a schematic diagram of the framework structure of the testing system provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of the testing device provided in the embodiments of this application; Figure 11 This is a schematic diagram of the hardware structure of a test device provided in an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of this application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

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

[0014] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0015] It should be noted that the terms "first, second, third" used in the embodiments of this application are used to distinguish similar or different objects and do not represent a specific order of objects. It can be understood that "first, second, third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0017] 1) Automated testing refers to the process of using specialized software tools, frameworks, and scripts to control the execution of tests and automatically compare actual results with expected results. The core of automated testing is to use machines (code) to replace or assist manual processes in completing the "execution" and "result verification" stages of testing activities.

[0018] Automated testing encompasses all types of tests that can be automated, such as unit testing, application programming interface (API) testing, user interface (UI) testing, and performance testing. Automated testing can improve efficiency, consistency, coverage, and feedback speed. It can be implemented through various methods, including writing code scripts, using recording and playback tools, or keyword-driven approaches.

[0019] 2) Script-driven testing refers to an automated testing method that creates test cases by directly writing programming code. Test logic, data, and verification points are all coded in scripts (such as those using Python, Java, or JavaScript). Script-driven testing is the most classic and flexible way to implement automated testing.

[0020] Script-driven testing is a specific technique or pattern for achieving automated testing. It transforms test steps into executable functions or methods, enabling fine-grained control over the test process, handling complex logic, and integration into development environments and continuous integration (CI) and continuous delivery (CD) pipelines.

[0021] To better understand the testing methods provided in the embodiments of this application, the testing methods and existing technical problems in related technologies will be explained first.

[0022] In related technologies, common production line automation testing platforms or frameworks have script testing capabilities as well as test results and logs. These platforms or frameworks can include general-purpose automation testing platforms, open-source continuous testing platforms, keyword-driven testing platforms, and so on.

[0023] Script-driven testing supports the use of various scripting languages ​​(such as Python, Java, etc.) or keyword scripts to describe test cases. Script testing also supports a certain degree of flow control, such as conditional statements, loops, and retries.

[0024] Test results and logs typically record whether the test passed or failed. Some platforms support test case-level and step-level logging. Some platforms also record information such as system version and environment variables.

[0025] In related technologies, the platform is biased towards software testing scenarios, lacking unified modeling for production line factories, projects, tests, script versions, and equipment configurations. The log structure does not fully match the production line's quality traceability requirements. Test scripts have a high barrier to entry, requiring production line test engineers to possess strong programming skills, which hinders rapid development and maintenance. Process control is often fragmented or overly complex, lacking unified abstraction for mechanisms such as failure jumps, abort jumps, and command-level jumps. Exception handling logic is complex and difficult to maintain. Furthermore, environment configuration settings (such as instrument addresses, serial ports, and thresholds) are often separated from logs, making it difficult to restore the original configuration environment after testing, affecting problem traceability.

[0026] Based on the above-mentioned technologies, it can be seen that the disadvantages of these technologies include at least the following: complex testing process, low test success rate, low testing flexibility, and poor adaptability.

[0027] To address the aforementioned problems in related technologies, this application provides a testing method. Since at least one target test item matches a selection operation, at least one target test item can be dynamically determined based on the selection operation. Based on this, at least one target test item is then parsed and executed. Because different selection operations correspond to different target test items, the flexibility of the test is improved. Since different selection operations correspond to different testing requirements, targeted testing is achieved, thereby improving the adaptability of the test.

[0028] The following describes exemplary applications of the testing equipment provided in the embodiments of this application. The testing equipment provided in the embodiments of this application can be implemented as a computer, server, server cluster, virtual machine, container, mobile phone, tablet, IoT device, simulator, emulator, etc.

[0029] Figure 1 This is a schematic diagram of the framework structure of the testing system provided in this application embodiment. Please refer to it. Figure 1 The testing methods provided in the embodiments of this application can be applied to a testing system 100, which includes a testing device 200 and a device under test (DUT) 300. For example, the testing device 200 can be a computer, and the DUT 300 can be a robot. The testing device 200 and the DUT 300 are connected via a network 400.

[0030] Taking the scenario of testing the device under test 300 through the test equipment 200 as an example, in order to support a test application, the test equipment 200 uses the test method provided in the embodiments of this application to perform performance testing on the device under test 300, which can improve the flexibility and adaptability of the test equipment 200.

[0031] In this embodiment, the testing device 200 can select at least one target test item from multiple test items based on a selection operation. That is, it obtains at least one target test item that matches the selection operation. Then, it parses and executes the at least one target test item. Since at least one target test item matches the selection operation, at least one target test item can be dynamically determined based on the selection operation, and then parsed and executed. Because different selection operations correspond to different at least one target test item, the flexibility of the test is improved. Since different selection operations correspond to different test requirements, targeted testing is achieved, thereby improving the adaptability of the test.

[0032] Figure 2 This is a flowchart illustrating a testing method provided in an embodiment of this application. This testing method can be applied to scenarios such as continuous integration and continuous delivery pipelines, regression testing, compatibility testing, performance, load and stress testing, verification testing, smoke testing, data-driven testing, microservice testing, and configuration and environment testing. The execution entity of this testing method can be a testing device, which can be a computer, a server, or a combination of both. Please refer to... Figure 2 The test method may include the following steps S201 to S203, which are described in detail below.

[0033] Step S201: Obtain the test script.

[0034] In this embodiment of the application, the test script includes multiple test items; the test script is determined based on test requirements and multiple preset functional modules, and each preset functional module is used to test the corresponding function.

[0035] In some embodiments, each test item is used to test a corresponding preset functional module. For example, for an underwater robot project, the test script may include 6 test items, which may be connecting the underwater robot, stopping the execution of the program, running the program, sensor testing, control testing, and motion testing.

[0036] In some embodiments, multiple preset functional modules can be considered as a functional module library. Based on this, a target functional module can be determined based on the test requirements and the multiple preset functional modules, and then a test script can be written based on the target functional module.

[0037] In some embodiments, the test device can obtain the test script from the central server based on a timestamp-triggered command or an externally triggered start command. For example, the test device obtains the test script from the central server at 12:00 every day.

[0038] In other embodiments, the test device may also obtain test scripts from a local path.

[0039] Step S202: In response to the selection operation of at least one target test item among multiple test items, at least one target test item is parsed to obtain the parsing result.

[0040] In some embodiments, the test item selected by the selection operation can be determined as the target test item, thus determining at least one target test item from a plurality of test items. Then, the at least one target test item constitutes a script to be run, which is then parsed to obtain a list of test items for each target test item in the script.

[0041] In other embodiments, if a script set consisting of multiple scripts to be run is parsed simultaneously, the script set is parsed first to obtain a script list; then each script to be run in the script list is parsed to obtain a test item list for each target test item in each script to be run.

[0042] Step S203: Execute at least one target test item based on the parsing results.

[0043] In some embodiments, each line in the script to be run corresponds to one target test item. Correspondingly, at least one target test item is arranged sequentially in the test item list, and the order of the at least one target test item in the test item list indicates its position in the script to be run. For example, if target test item 1 is arranged in the test item list as number 1, then target test item 1 is located in the first line of the script to be run. Based on this, at least one target test is executed sequentially according to the order indicated by the parsing result.

[0044] During the implementation process, the parsing results also include the executable file for each target test item, so the corresponding target test item can be executed based on the executable file of each target test item.

[0045] The above testing method allows for the selection of at least one target test item from multiple test items based on a selection operation. This means obtaining at least one target test item that matches the selection operation. Then, this at least one target test item is parsed and executed. Since at least one target test item matches the selection operation, at least one target test item can be dynamically determined based on the selection operation, and then parsed and executed. Because different selection operations correspond to different at least one target test item, the flexibility of the testing is improved. Furthermore, because different selection operations correspond to different testing requirements, targeted testing is achieved, thereby improving the adaptability of the testing.

[0046] In some embodiments, at least one target test item includes a first target test item, and the parsing result includes the first test item identifier and the number of retries corresponding to the first target test item. Figure 3 This is a flowchart illustrating one of the execution target test items provided in an embodiment of this application. Please refer to it. Figure 3 The above step S203 can be achieved through the following steps S031 to S036, which will be explained in detail below.

[0047] Step S031: Execute the first target test item corresponding to the first test item identifier to obtain the first execution result.

[0048] In some embodiments, the first target test item can be any one of at least one target test item, which is the target test item to be executed. For example, the first target test item can be the test item with the order 1 in the above list of test items.

[0049] In the implementation process, the target executable file corresponding to the first target test item can be determined from multiple executable files by using the first test item identifier; then, the target executable file is run to obtain the first execution result for the first target test item. For example, the first test item identifier can be TI001.

[0050] In some embodiments, the number of retries corresponding to the first target test item can refer to the number of times the first target test item is executed again if the first target test item fails. For example, the number of retries can be 0, 1, 2, etc.

[0051] Step S032: Determine if the number of retries is zero.

[0052] In some embodiments, if the number of retries is zero, then proceed to step S033; and if the number of retries is not zero, that is, if the number of retries is greater than zero, then proceed to step S035.

[0053] Step S033: Determine a second target test item from at least one target test item based on the first execution result.

[0054] At this point, the number of retries is zero, indicating that the first target test item will not be re-executed, even if it fails. The second target test item is then determined from at least one target test item based on the first execution result.

[0055] During implementation, the first execution result can include execution success and execution failure. Based on this, if execution succeeds, the target test item that is adjacent to and follows the first target test item in the test item list can be determined as the second target test item. If execution fails, a preset test item can be determined as the second target test item; alternatively, the failure jump item indicated by the parsing result can be determined as the second target test item.

[0056] Step S034: Execute the second target test item. Then end the process.

[0057] In some embodiments, the executable file corresponding to the second target test item can be obtained first, and then the executable file corresponding to the second target test item can be executed. The process of executing the second target test item is similar to the process of executing the first target test item in step S031 above, and will not be repeated here.

[0058] Step S035: If the first execution result is unsuccessful, continue executing the first target test item.

[0059] At this point, the number of retries is not zero, indicating that the first target test item can still be re-executed. That is, if the first target test item fails, it can continue to be executed.

[0060] In other embodiments, if the first execution result is pass, the index of the second target test item is determined based on the index of the first target test item, and the second target test item indicated by the index of the second target test item is executed. Here, the index represents the execution order of the target test items, the position of the target test item in the aforementioned test item list, and the position of the target test item in the script to be run. For example, the index of the first target test item can be 1; then, incrementing the index of the first target test item by 1 yields the index of the second target test item, i.e., the index of the second target test item is 2. Based on this, the second target test item corresponding to 2 is determined from at least one target test item in the mapping table between the index and the test item.

[0061] Step S036: Decrement the number of retries by 1, and update the parsing result corresponding to the first target test item based on the decremented number of retries.

[0062] In some embodiments, since the first target test item is executed again in step S035, the retry count corresponding to the first target test item is decremented by 1. For example, if the retry count is 3 before executing step S035, then the retry count is updated to 2 after executing step S035.

[0063] In other embodiments, after obtaining the first execution result, it may be determined whether the first execution result is successful. If the first execution result is successful, the index of the second target test item is determined based on the index of the first target test item, and the second target test item indicated by the index of the second target test item is executed. If the first execution result is unsuccessful, it is determined whether the number of retries is zero. If the number of retries is zero, the test item indicated by the jump test item identifier is determined as the second target test item, and the second target test item is executed; if the number of retries is not zero, the first target test item is executed, and the above step S306 is executed.

[0064] Through the aforementioned process of executing target test items, the system's automatic retries effectively filter noise and prevent interruptions or false defect reports caused by occasional failures due to environmental transients (such as network jitter or resource contention), ensuring that test results better reflect the actual product quality. This improves test stability. When the number of retries is exhausted or no retries are needed, the system can intelligently select the next test item (the second target test item) based on the current result. This achieves a dynamic test sequence, skipping known blocked test branches and executing other tests more likely to pass, maximizing the information acquired in a single test execution. This optimizes execution efficiency. The embedded real-time management (decrementing and updating) of retry counts makes the retry logic of each test item independently controllable. This design upgrades the retry strategy from static configuration to a dynamic process that can be adjusted according to the execution state, enhancing the system's adaptability and achieving closed-loop control.

[0065] In some embodiments, the first execution result includes execution successful and execution unsuccessful; the parsing result also includes a jump test item identifier. Based on this, Figure 4 This is a flowchart illustrating a method for determining a second target test item, as provided in an embodiment of this application. Please refer to it. Figure 4 The above step S033, "determine the second target test item from at least one target test item based on the first execution result", can be achieved through the following steps S331 to S333, which are explained in detail below.

[0066] Step S331: Determine whether the first execution result is successful.

[0067] In some embodiments, if the first execution result is "execution passed," indicating that the first target test item has been successfully executed, then proceed to step S332. If the first execution result is not "execution passed," then the first execution result is "execution failed," indicating that the first target test item has not been successfully executed; otherwise, proceed to step S333.

[0068] Step S332: Determine the index of the second target test item based on the index of the first target test item. Then end the process.

[0069] At this point, the first execution result is "execution passed," indicating that the first target test item was successfully executed. The index of the first target test item is then incremented by 1 to obtain the index of the second target test item.

[0070] Step S333: The test item indicated by the jump test item identifier is identified as the second target test item.

[0071] At this point, the first execution result is "execution failed," indicating that the first target test item was not successfully executed. Then, the test item indicated by the jump test item identifier in the parsed result is determined from at least one target test item, and this jump test item identifier is identified as the second target test item. The jump test item identifier can be pre-set based on experience; this identifier represents the test item required to be executed under different conditions of the first target test item's execution.

[0072] The process of determining the second target test item described above changes the traditional linear execution mode, allowing the test flow to dynamically select paths based on actual results. When a test passes, it proceeds in a predetermined order (based on an index) to ensure coverage. When a test fails, it triggers pre-defined jump logic, directing the execution flow to more relevant test items, giving the test sequence context-aware capabilities and enabling intelligent process navigation. When a test item fails, the system can automatically skip subsequent tests that may depend on that function or be on the same fault chain (these tests are also likely to fail), and instead execute diagnostic, alternative, or independent tests specified by the jump flag. This avoids meaningless consecutive failures, quickly converges to the problem boundary, and improves fault location efficiency, thereby enhancing fault isolation and diagnosis efficiency. By avoiding the execution of test items that are necessarily invalid or redundant in specific failure scenarios, valuable test time, computing resources, and equipment usage costs are saved. At the same time, it guides the execution of more valuable tests, enabling a single test run to obtain the maximum effective quality feedback.

[0073] In some embodiments, execution failure includes execution failure and execution abort; the jump test item identifier includes a failure jump identifier and an abort jump identifier. Based on this, Figure 5 This is another flowchart illustrating the determination of the second target test item provided in this application embodiment. Please refer to it. Figure 5 The step S333 above, "determining the test item indicated by the jump test item identifier as the second target test item", can be achieved through the following steps S31 to S33, which are explained in detail below.

[0074] Step S31: Determine whether the first execution result is an execution failure.

[0075] In some embodiments, if the first execution result is "execution failed," it is further determined whether the first execution result is "execution aborted." If the first execution result is "execution aborted," it indicates that the first target test item was completed, but an unexpected execution result was obtained, and then proceed to step S32. If the first execution result is not "execution aborted," it indicates that the first target test item was not completed, but the execution task was unexpectedly terminated during the execution of the first target test item, and then proceed to step S33.

[0076] Step S32: Identify the test item indicated by the failure jump flag as the second target test item. Then end the process.

[0077] At this point, the first execution result is execution failure. Then, the test item indicated by the failure jump flag is determined from at least one target test item, and the test item indicated by the failure jump flag is determined as the second target test item.

[0078] Step S33: The test item indicated by the abort jump flag is identified as the second target test item.

[0079] At this point, the first execution result is execution abort. Then, the test item indicated by the abort jump flag is determined from at least one target test item, and the test item indicated by the abort jump flag is determined as the second target test item.

[0080] By defining the second target test item as described above, "execution failure" is subdivided into execution failure (logical error) and execution abort (unexpected interruption), and independent jump paths are configured for each. This allows the system to guide the execution flow to relevant subsequent steps based on the nature of the failure. For example, after failure, it can jump to a specific verification test for in-depth confirmation; after abort, it can jump to an environmental health check or connection recovery test. This improves the targeting of problem localization and enables precise problem triage and diagnosis. By distinguishing between "logical error" and "unexpected interruption," the system can adopt more appropriate recovery strategies. For aborts (usually caused by environmental issues), jumping to an environmental check or alternative test item may provide the system with the opportunity for automatic recovery or switching to a backup solution, thus continuing to obtain valuable test information even when some components fail, improving the resilience of the overall process. It also enhances the robustness and self-healing capability of the test process. It avoids ineffective operations caused by mixing errors of different natures. For example, it will not execute a series of functional tests that depend on hardware (which will inevitably fail) after an abort caused by a hardware connection failure. Instead, switch directly to problem diagnosis or independent test sets to optimize test resource and time allocation.

[0081] In some embodiments, if the first execution result is that the execution fails... Figure 6This is a flowchart illustrating a method for determining a jump test item identifier according to an embodiment of this application. Please refer to it. Figure 6 Before performing step S333, steps S001 and S002 may also be performed: Step S001: Obtain the category information of the first execution result.

[0082] In some embodiments, if the first execution result is an execution failure, the category information of the first execution result can also be determined. This category information is used to characterize the error classification. For example, the category information may include test equipment failure, connectivity problem, power problem, test fixture problem, network problem, insufficient resources, etc.

[0083] Step S002: Based on the category information of the first execution result and the preset correspondence, determine the jump test item identifier.

[0084] In the embodiments of this application, the preset correspondence is used to indicate the correspondence between multiple category information and multiple test item identifiers, and different category information corresponds to different test item identifiers.

[0085] In some embodiments, a test item identifier corresponding to the category information can be determined based on a preset correspondence, and the test item identifier corresponding to the category information can be determined as the jump test item identifier.

[0086] By determining the jump test item identifier using the above method, jumps are no longer based solely on rough states like "pass / fail / abort," but rather on the specific error category (such as "network timeout," "database connection failure," "calculation logic error," etc.). This upgrades the test response strategy from a "one-size-fits-all" approach to a "tailored approach," improving processing accuracy and enabling refined and personalized process navigation. Through the preset mapping relationship between error categories and test items, the system can automatically trigger the most efficient diagnostic chain or verification sequence. For example, when a "voltage over-limit" error is detected, it automatically jumps to the "power supply calibration test"; when a "UI rendering error" is detected, it jumps to the "screenshot and OCR verification test." This is equivalent to configuring an expert-level processing flow for each type of problem, accelerating root cause localization and enhancing the automation depth of test diagnosis. The preset mapping relationship (such as a configuration table or rule engine) decouples the jump logic from the test script itself. When a new error handling strategy or jump logic needs to be added or adjusted, only the mapping relationship configuration needs to be modified, without the need for in-depth modifications to a large number of test scripts, resulting in low maintenance costs and flexible expansion. This improves the maintainability and scalability of the test suite.

[0087] In some embodiments, Figure 7 This is another flowchart illustrating the execution of the target test item provided in this application embodiment. Please refer to it. Figure 7After step S034 and / or step S036, steps S037 and S038 can also be performed, as explained in detail below.

[0088] Step S037: Adjust the number of retry attempts and / or the jump test item identifier based on the first execution result.

[0089] In some embodiments, the test result for the first target test item can be determined based on the first execution result and the historical execution results for the first target test item. Then, based on the test result for the first target test item, at least one of the adjusted retry count and the jump test identifier for the first target test item is adjusted. The adjusted retry count and / or the adjusted jump test item identifier are obtained.

[0090] For example, if the probability that the first execution result of the first target test item is failure is greater than a probability threshold, the number of retries can be increased, meaning the number of times the first target test item is re-executed increases. The probability threshold can be a value pre-set based on experience; for example, it could be 50%, 60%, etc. Furthermore, if the probability that the first execution result of the first target test item is failure is greater than the probability threshold, the jump test item identifier can be changed from identifier 1 to identifier 2.

[0091] Step S038: Update the parsing result corresponding to the first target test item based on the adjusted number of retries and / or the adjusted jump test item identifier.

[0092] In some embodiments, if the first target test item is parsed during its first execution and the parsing result corresponding to the first target test item is stored locally, then the retry count and / or jump test item identifier in the parsing result corresponding to the first target test item are updated based on the adjusted retry count and / or the adjusted jump test item identifier. For example, assuming step S037 adjusts the retry count and jump test item identifier, the retry count in the parsing result corresponding to the first target test item is updated to the adjusted retry count, and the jump test item identifier in the parsing result corresponding to the first target test item is also updated to the adjusted jump test item identifier.

[0093] Through the aforementioned process of updating the retry count and jump test item identifiers, and by automatically adjusting the retry strategy (e.g., increasing the number of retries for occasional network errors) or optimizing the jump path (e.g., associating more precise diagnostic processes for frequently occurring new defect types) based on real-time feedback of execution results (such as error type and failure frequency), the system can continuously learn and optimize its behavior during operation. This not only significantly improves the intelligence and fault tolerance of a single test execution, but also, through real-time updates of the parsing results, enables the entire test suite to have the ability to evolve and improve incrementally, gradually approaching the optimal test strategy without manual intervention, thus achieving dynamic adaptive configuration capabilities.

[0094] In some embodiments, during the execution of step S203 above, the following may also be performed: displaying test progress and test pause control; the test progress includes test completion rate, and the test pause control is used to pause at least one test item that is being executed.

[0095] In some embodiments, the test progress is used to characterize the progress of executing at least one target test item, and the test progress can be displayed in the form of a progress bar. The test pause control is a triggerable control, which can be triggered to pause the execution of at least one target test item.

[0096] In some embodiments, the test progress also includes a test completion rate, which can be represented by characters, a progress bar filled with color, or the percentage of the total progress. For example, the test completion rate can be 60%, 70%, etc.

[0097] In some embodiments, after performing step S203 above, the following may also be performed: displaying test results and a test start control; the test results are used to indicate whether at least one target test item has been successfully executed, and the test start control is used to execute at least one test item.

[0098] In some embodiments, the test results can be presented in tabular form, including the test item identifier and execution result for each target test item. Each target test item corresponds to one row in the table. The execution result can include execution passed and execution failed; execution passed can be indicated by a first identifier, and execution failed can be indicated by a second identifier.

[0099] The real-time progress bar displayed through the aforementioned visual interface provides users with clear expectations and status feedback for task execution, avoiding "black box" waiting. Simultaneously, the test pause control empowers users to immediately interrupt testing in emergencies or when problems are discovered, enabling manual intervention and takeover of the automated process and improving operational flexibility. It also enhances process visibility and user control. The centralized display of test results after testing (such as pass / fail overview and key metrics) provides users with quick and direct quality assessment. The subsequent test start control forms a clear operational loop: after viewing the results, a new round of testing can be initiated directly on the same interface without switching contexts or performing complex steps, greatly simplifying the workflow and improving test iteration efficiency.

[0100] In some embodiments, Figure 8 This is another flowchart illustrating the testing method provided in this application embodiment. Please refer to it. Figure 8 After step S203, steps S204 and S205 can also be executed, which will be explained in detail below.

[0101] Step S204: Receive the device identifier of the device under test, and generate a test log based on the device identifier and the execution result of at least one target test item.

[0102] In some embodiments, an input module is deployed on the test device, which can obtain the device identifier of the device under test in response to the input information or scanning information of the input module.

[0103] In some embodiments, the device identifier and the execution result of at least one target test are bound together to obtain the test log of the device under test.

[0104] Step S205: In response to the command to view the test log, display the test log.

[0105] In this embodiment of the application, the information corresponding to the target test item that was successfully executed in the test log is displayed using a first display parameter, and the information corresponding to the target test item that failed to execute in the test log is displayed using a second display parameter.

[0106] In some embodiments, in order to quickly locate the target test item that failed to execute, the second display parameter can be more conspicuous than the first display parameter. For example, the first display parameter can be a display parameter with green font and the second display parameter can be a display parameter with red font.

[0107] By generating and displaying the logs described above, test results are strongly correlated with the device identifier of the device under test (DUT). The generated logs not only record "which test items passed or failed," but also specify "on which specific DUT it occurred," which is crucial for multi-device parallel testing, problem reproduction, and hardware defect tracking. This enables precise traceability and accountability. By differentiating success and failure items using a first display parameter (e.g., green) and a second display parameter (e.g., red), users can instantly capture key information and quickly locate the failure point when viewing the logs. This high-contrast visual design transforms massive amounts of text logs into easily scannable visual reports, shortening the time required for manual review and root cause analysis. It provides intuitive result visualization and rapid diagnosis. The structured logs facilitate storage, querying, and subsequent analysis, providing a reliable data foundation for test quality assessment, device health trend analysis, and process auditing. This enhances data manageability.

[0108] The following will describe an exemplary application of the embodiments of this application in a practical application scenario.

[0109] The testing methods provided in this application can be applied to integrated testing platforms on production lines for electronic products, modules, and complete machines during the manufacturing process, such as functional or performance testing of camera modules, printed circuit board assemblies (PCBAs), and complete terminal devices.

[0110] The testing methods provided in this application can be applied in production line workstations for functional testing, aging testing, calibration testing, etc. Users can select the factory, project, test type, and script through a graphical interface to perform automated testing on the product under test. The product under test corresponds to the device under test in other embodiments.

[0111] The testing method provided in this application embodiment may include test script parsing, test item selection, execution flow control, communication with various instruments or fixtures, barcode scanning, recording test results, and generating logs. Based on this, after the test, logs enable efficient traceability of problematic products, problematic script versions, and problematic configurations. For example, the testing method can be applied to a Windows operating environment, and the development language can be Python, PySide6, C#, Java, Qt, etc. The deployment form can be local deployment or server script or configuration storage.

[0112] This application also provides a testing system, which can be a script-driven test process control and log traceability system for production lines. Figure 9 This is a schematic diagram of the framework structure of the testing system provided in this application embodiment. Please refer to it. Figure 9The test system 100 consists of a script parsing and control module 901, a command interpretation and execution module 902, a test session and log management module 903, a UI interaction module 904, and a configuration management module 905.

[0113] In some embodiments, script module files can be in formats such as text, structured data files, or databases. Taking a text-based script module file as an example, the script module file can be divided into different test script blocks using text tags labeled "script name". Within each script block, each line describes a test item, and the format of the test item can be "test item name -> number of retries, jump on failure, jump on abort or test item name". Script modules can be parsed using script parsing functions to obtain a list of scripts. For example, the script parsing function can be `ScriptParser.parse_script_module_file`. The list of test items under a script can also be parsed using project parsing functions to generate parsed content. For example, the item parsing function can be ScriptParser.parse_script_test_items(file_path, script_name). The parsed content can include display text (display_text), full content (full_content), line number (line_num), and whether it is a comment item (is_commented). The display text is the name of the test item displayed in the UI; the full content contains the complete content of the flow control parameters; the line number represents the line number in the script file; and whether it is a comment item indicates whether the line is a comment item.

[0114] In some embodiments, the functional module files in the script parsing and control module 901 can be in formats such as text, structured data files, and databases. Taking a text format functional module file as an example, the functional module file can be divided into functional modules using text tags labeled "module name," and each module consists of multiple lines of commands. The format of each command line can be "command name => parameter 1, parameter 2, parameter 3." All module names can be obtained through a module name retrieval function; for example, the module name retrieval function can be ScriptParser.parse_function_module_file. A command retrieval function can also be used to retrieve the command list for each module; for example, the command retrieval function can be ScriptParser.parse_function_module_commands(file_path, module_name).

[0115] In some embodiments, the test flow control engine controls the test item-level flow. After the user selects a script and checks test items in the UI, the selection of test items is achieved through a selection function. For example, this selection function could be `_execute_test_sequence(checked_items)`. Next, the test item parsing function parses out the functional module name (module_name), the number of retries (retry_count), the target test name to jump to on failure (fail_jump), and the target test name to jump to on abort (abort_jump). For example, the test item parsing function could be `_parse_flow_control(full_content)`.

[0116] In some embodiments, the test flow control engine maintains an item map (test_item_map), which maps display text (display_text) to indexes for navigation based on name.

[0117] In some embodiments, the failure redirection and abort redirection mechanism includes failure redirection and abort redirection. Failure redirection includes: if a test item fails to execute and has a failure redirection target test name, then redirection to the test item indicated by the failure redirection target test name continues execution; otherwise, subsequent tests are terminated. Abort redirection includes: when a user aborts a test, if the current item is configured with an abort redirection target test name, the system automatically redirects to the test item indicated by the abort redirection target test name for execution, and then terminates the process after execution.

[0118] In other embodiments, after detecting a change in the is_testing status, the test process control engine handles the test items after abort by jumping to the target test name flag and the project mapping table during abort.

[0119] In some embodiments, the testing method of this application further includes command-level jumps and exception handling. Within the functional module, special command-driven jump test items are supported. When an exception class is detected and thrown in the running function, the exception class is captured by a capture function, and the jump target item in the exception class is determined as the test item-level jump target, thereby realizing command-driven cross-test item jumps. For example, the running function can be _execute_single_command, the exception class can be TestJumpException(target_item), target_item is the jump target item, and the capture function can be _execute_test_sequence.

[0120] In some embodiments, the testing method of this application further includes a condition judgment and loop control mechanism, supporting commands such as if, otherwise, end judgment, loop, and end loop.

[0121] In some embodiments, within the function execution function, when the if or otherwise condition returns "no", a navigation function jumps to the corresponding otherwise or end condition line, achieving block-level skipping. The function execution function can be `_execute_function_module`, and the navigation function can be `_find_next_condition_block`.

[0122] In other embodiments, when the loop returns "No", a jump to the corresponding ending loop is initiated via an end-find function. This end-find function can be `_find_loop_end`.

[0123] In some embodiments, when the loop ends and a message containing a backtrack index is returned, the command index is backtracked to achieve loop control. For example, the message containing the backtrack index could be LOOP_BACK:x.

[0124] In some embodiments, a readable loop structure is achieved by recording the loop label and starting index through interfaces such as setting the loop start position.

[0125] In some embodiments, the command interpretation and execution module parses the command line output using a text parsing function, extracts the command name and parameter strings, and splits the parameters according to Chinese and English commas; it intelligently converts the string into integers, floating-point numbers, or strings using the parameter parsing function (_parse_param). The text parsing function can be _parse_test_command((command_line).

[0126] In some embodiments, the command map (COMMAND_MAP) is defined in the execution function _execute_single_command(command_name, params) to map Chinese command names to underlying driver functions, such as scanning serial number (SN), connecting to the driver, closing the driver, sending in a loop, judging the content of the returned packet, extracting the content of the returned packet, displaying a dialog box, and displaying a video.

[0127] In some embodiments, the start and end times are recorded before and after command execution, the time elapsed is calculated, and the logging module is called to record the results. For example, the time elapsed can be in the millisecond range.

[0128] In some embodiments, the test session structure and log file naming in the aforementioned test session and log management module can be achieved by creating sessions through session functions. For example, the session function can be `TestLogger.start_session(sn, factory, project, test, script, all_config_vars)`, where the parameters of the session function include the serial number, factory, project, test, and script name; the parameters also include start and end times, total time elapsed, result, and whether manual stopping was performed; the parameters also include a list of test items and statistics; and the parameters also include snapshots of all configuration variables. Based on this, a filename is generated using `project_root / log / factory / project / test / date / ` as the directory, for example, `SN_test_script_time_in progress.log`. Afterwards, it can be renamed to the final file according to the session end status.

[0129] In some embodiments, the multi-dimensional information (_write_header) written in the log header of the aforementioned test session and log management module includes the platform version and update time, script version and update time, serial number (SN), factory, project, test, script name, system platform information, Python version, local IP address, and all automatically loaded configuration variables. The platform version and update time can be read from config / about_info.json, the script version and update time can be obtained by matching the test name _Vx.yzzip in the server script directory, taking the highest version and file modification time, and all configuration variables can include name, value, source category, etc.

[0130] In some embodiments, local / server script paths can be managed uniformly through functions for obtaining the script base path and obtaining the server script path. For example, the function for obtaining the script base path can be `_get_script_base_path`, and the function for obtaining the server script path can be `_get_server_script_dir`.

[0131] In some embodiments, the declaration function in the test item-level and command-level log structures includes the test item start time, index, and name, and outputs a separator line and the start line in the log. For example, the declaration function could be start_test_item(name).

[0132] In some embodiments, the operation log includes a command number, command content, result (pass or fail), duration, and detailed message, with different symbols used to distinguish the result. For example, the operation log can be represented as log_command(command, result, message, duration_ms).

[0133] In some embodiments, the end-of-test item includes the test item end time, result, and total time; if there is an error message, an additional record is appended. For example, the end-of-test item can be represented as end_test_item(result, error_msg), where result represents the result and error_msg represents the error message.

[0134] In some embodiments, for the coordinated test completion and driver cleanup, before the capture function (_execute_test_sequence) ends, the function to clean up all drivers (self.test_logger) is called, closing all device connections and writing the closing status to the log. Then, the function to end the logging session is called, and the final session result is determined by combining the execution result, failure count, whether manual stopping was performed, and whether the jump was aborted. For example, the function to end the logging session can be self.test_logger.end_session(final_result, is_manual_stop).

[0135] In some embodiments, a closed loop between UI control and serial number (SN) is implemented. A single-row test information table is created in the UI through an interface initialization function. The test information table may include: workstation, window number, test control button (start / stop test), status column, serial number column (SN), and progress column (progress bar). For example, the interface initialization function can be `_populate_test_info_table`.

[0136] In some embodiments, the state switching function switches the UI state to "Testing", resets the sequence number, creates a progress bar, and clears the test results table. For example, the state switching function could be `_update_ui_for_test_start`.

[0137] In some embodiments, during the execution of a functional module, after the command "scan SN" is successfully executed, the SN is read from a global variable via a barcode update function and automatically updated to the barcode column. For example, the barcode update function could be _update_barcode_from_scan(variable_name).

[0138] In some embodiments, the capture function (_execute_test_sequence) performs data confirmation (start_session) only when the test item is actually executed for the first time, and reads the SN from the variable to ensure that the SN recorded in the log is consistent with the actual barcode.

[0139] In the implementation process, in addition to retries, failure redirects, and abort redirects, different redirects based on error codes can be added; the number of retry attempts or redirect logic can be dynamically adjusted based on test history results; and multi-target redirection rules are supported. Furthermore, the single-window structure can be extended to a multi-station parallel structure, with each station having an independent session and log file, or sharing sub-files under the same log directory. This enables multi-station or multi-threaded parallel testing. Finally, in addition to text files, log output can be synchronously written to databases, middleware, or Manufacturing Execution Systems (MES) and quality systems to achieve automated quality analysis and traceability. This facilitates integration with external systems.

[0140] The testing method provided in this application offers a Chinese script syntax and a unified process control model for production line engineers. It lowers the barrier to script writing and maintenance through lightweight text syntax such as "script name," "module name," "command => parameters," and "test item name -> retry count, failure jump, abort jump," combined with a graphical interface. A unified parsing and execution engine abstracts and manages process control mechanisms such as retries, failure jumps, abort jumps, command-level jumps, conditional judgments, and loops. Furthermore, a multi-dimensional, integrated test session and log traceability system can uniformly record SN, factory, project, test, script name, platform version, script version and update time, snapshots of all configuration variables, test item-level and command-level execution details and time consumption, and the cleanup status of driving resources in a single log file. This enables rapid location of problematic batches of products, determining whether the issue is due to a script version problem, configuration problem, equipment resource problem, or a problem with the device under test itself.

[0141] This application embodiment also binds barcode scanning, global variables, UI display, logging, and process initiation into a closed loop. The logging session is only initiated after a successful scan and serial number writing, ensuring the accuracy and uniqueness of the serial number in the log, thus achieving closed-loop control of the serial number and test barcode process. Finally, before the test ends, a unified call to the driver cleanup interface is made and the log is written, enabling accurate tracing of device resource leaks or anomalies, which helps improve the long-term operational stability of the production line system. This achieves unified driver lifecycle and log collaborative recording.

[0142] It should be understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0143] Based on the foregoing embodiments, this application provides a testing device, which includes various modules and units included in each module, and can be implemented by a processor; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field-programmable gate array (FPGA), etc.

[0144] Figure 10 This is a schematic diagram of the testing device provided in the embodiments of this application. Please refer to it. Figure 10 In another aspect of the embodiments of this application, a testing device is also provided, which includes: a first acquisition module 1001, a parsing module 1002, and an execution module 1003; The first acquisition module 1001 is used to acquire a test script, which includes multiple test items. The test script is determined based on test requirements and multiple preset functional modules, and each preset functional module is used to test the corresponding function. The parsing module 1002 is configured to, in response to the selection operation of at least one target test item among the plurality of test items, parse the at least one target test item and obtain a parsing result; Execution module 1003 is used to execute the at least one target test item based on the parsing result.

[0145] In some embodiments, the at least one target test item includes a first target test item, and the parsing result includes a first test item identifier and a retry count corresponding to the first target test item; the execution module 1003 is further configured to execute the first target test item corresponding to the first test item identifier to obtain a first execution result; when the retry count is zero, determine a second target test item from the at least one target test item based on the first execution result; and execute the second target test item.

[0146] In some embodiments, the first execution result includes execution passed and execution failed; the parsing result further includes a jump test item identifier; the execution module 1003 is further configured to, if the first execution result is execution passed, determine the index of the second target test item based on the index of the first target test item; if the first execution result is execution failed, determine the test item indicated by the jump test item identifier as the second target test item.

[0147] In some embodiments, the execution failure includes execution failure and execution abort; the jump test item identifier includes a failure jump identifier and an abort jump identifier; the execution module 1003 is further configured to, in the case that the first execution result is the execution failure, determine the test item indicated by the failure jump identifier as the second target test item; and in the case that the first execution result is the execution abort, determine the test item indicated by the abort jump identifier as the second target test item.

[0148] In some embodiments, the testing apparatus further includes a second acquisition module and a first determination module. The second acquisition module is used to acquire category information of the first execution result. The first determination module is used to determine the jump test item identifier based on the category information of the first execution result and a preset correspondence. The preset correspondence is used to indicate the correspondence between multiple category information and multiple test item identifiers, and different category information corresponds to different test item identifiers.

[0149] In some embodiments, the testing apparatus further includes an adjustment module, configured to adjust the number of retries and / or the jump test item identifier based on the first execution result, and update the parsing result corresponding to the first target test item based on the adjusted number of retries and / or the adjusted jump test item identifier.

[0150] In some embodiments, the execution module 1003 is further configured to, if the first execution result is unsuccessful when the number of retries is not zero, continue to execute the first target test item; decrement the number of retries by 1, and update the parsing result corresponding to the first target test item based on the decremented number of retries.

[0151] In some embodiments, the testing apparatus further includes a first display module and a second display module. The first display module is used to display test progress and a test pause control during the execution of the at least one target test item; the test progress includes test completion, and the test pause control is used to pause the execution of the at least one test item. The second display module is used to display test results and a test start control after the execution of the at least one target test item; the test results are used to indicate whether the at least one target test item has passed, and the test start control is used to execute the at least one test item.

[0152] In some embodiments, the testing apparatus further includes a generation module and a third display module. The generation module is configured to receive a device identifier of the device under test and generate a test log based on the device identifier and the execution result of the at least one target test item. The third display module is configured to display the test log in response to a viewing instruction. The information corresponding to the successfully executed target test item in the test log is displayed using a first display parameter, and the information corresponding to the unexecuted target test item in the test log is displayed using a second display parameter.

[0153] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0154] It should be noted that, in the embodiments of this application... Figure 10 The module division of the control device shown is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or be integrated into one unit from two or more other units. The integrated units described above can be implemented in hardware, as software functional units, or in a combination of both.

[0155] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a test device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0156] Figure 11 This is a schematic diagram of a hardware structure of the testing device provided in an embodiment of this application. Please refer to it. Figure 11 This application provides a testing device, which may include, but is not limited to, a computer, server, server cluster, virtual machine, container, mobile phone, tablet, IoT device, simulator, emulator, etc. The functions implemented by this method can be achieved by the processor in the testing device calling program code, which can be stored in a computer-readable storage medium.

[0157] The internal structure diagram of the testing equipment can be seen as follows: Figure 11 As shown. The test device includes a processor 1102 and a memory connected via a system bus 1101. The processor 1102 provides computing and control capabilities; it can be, for example, a CPU, or a combination of a CPU and a GPU, etc., without specific limitations. The memory of the test device may include a non-volatile storage medium 1031 and internal memory 1032. The non-volatile storage medium 1031 stores the operating system, computer programs, and a database. The internal memory 1032 provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium 1031. The database of the test device is used to store data. When the computer program is executed by the processor 1102, it implements the aforementioned test method.

[0158] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method provided in the above embodiments.

[0159] This application provides a computer program product containing a computer program or computer-executable instructions, which, when run on a computer, causes the computer to perform the steps in the method provided in the above-described method embodiments.

[0160] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the test equipment on which the present application is applied. Specific test equipment may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0161] In one embodiment, the control device provided in this application can be implemented as a computer program, and the computer program can be implemented in such a way as... Figure 11 The test apparatus shown operates on the device. The memory of the test apparatus can store the various program modules that make up the above-described apparatus. The computer program comprised of the various program modules causes the processor to execute the steps of the methods in the various embodiments of this application described in this specification.

[0162] It should be noted that the descriptions of the computer-readable storage medium and testing equipment embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the embodiments of the testing apparatus, testing equipment, computer-readable storage medium, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0163] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0164] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0165] In addition, each functional module in the various embodiments of this application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the integrated modules can be implemented in hardware or in the form of hardware plus software functional units.

[0166] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0167] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a test device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0168] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0169] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0170] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0171] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A testing method, characterized in that, The method includes: Obtain a test script, which includes multiple test items; the test script is determined based on test requirements and multiple preset functional modules, each of the multiple preset functional modules being used to test the corresponding function; In response to the selection of at least one target test item among the plurality of test items, the at least one target test item is parsed to obtain the parsing result; Execute at least one target test item based on the parsing results.

2. The test method according to claim 1, characterized in that, The at least one target test item includes a first target test item, and the parsing result includes the first test item identifier and the number of retries corresponding to the first target test item; Executing the at least one target test item based on the parsing result includes: Execute the first target test item corresponding to the first test item identifier to obtain the first execution result; If the number of retries is zero, a second target test item is determined from the at least one target test item based on the first execution result; Execute the second target test item.

3. The method according to claim 2, characterized in that, The first execution result includes execution successful and execution unsuccessful; the parsing result also includes a jump test item identifier; Determining the second target test item from the at least one target test item based on the first execution result includes: If the first execution result is that the execution is successful, the index of the second target test item is determined based on the index of the first target test item; If the first execution result is that the execution fails, the test item indicated by the jump test item identifier is determined as the second target test item.

4. The method according to claim 3, characterized in that, The execution failure includes execution failure and execution abort; the jump test item identifier includes failure jump identifier and abort jump identifier; The step of determining the test item indicated by the jump test item identifier as the second target test item includes: If the first execution result is execution failure, the test item indicated by the failure jump flag is determined as the second target test item; If the first execution result is execution abort, the test item indicated by the abort jump flag is determined as the second target test item.

5. The method according to claim 3, characterized in that, Before determining the test item indicated by the jump test item identifier as the second target test item, the method further includes: Obtain the category information of the first execution result; Based on the category information of the first execution result and the preset correspondence, the jump test item identifier is determined; wherein, the preset correspondence is used to indicate the correspondence between multiple category information and multiple test item identifiers, and different category information corresponds to different test item identifiers.

6. The method according to claim 3, characterized in that, The method further includes: The retry count and / or the jump test item identifier are adjusted based on the first execution result, and the parsing result corresponding to the first target test item is updated based on the adjusted retry count and / or the adjusted jump test item identifier.

7. The method according to claim 2, characterized in that, Executing the at least one target test item based on the parsing result includes: If the number of retries is not zero, and the first execution result is a failure, the first target test item continues to be executed. Decrement the number of retries by 1, and update the parsing result corresponding to the first target test item based on the decremented number of retries.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: During the execution of the at least one target test item, a test progress and a test pause control are displayed; the test progress includes the test completion rate, and the test pause control is used to pause the execution of the at least one test item. After executing the at least one target test item, the test result and test start control are displayed; the test result is used to indicate whether the at least one target test item has been executed successfully, and the test start control is used to execute the at least one test item.

9. The method according to any one of claims 1 to 7, characterized in that, After executing the at least one target test item based on the parsing result, the method further includes: Receive the device identifier of the device under test, and generate a test log based on the device identifier and the execution result of the at least one target test item; In response to a viewing command for the test log, the test log is displayed; wherein, the information corresponding to the target test items that were successfully executed in the test log is displayed using a first display parameter, and the information corresponding to the target test items that failed to execute in the test log is displayed using a second display parameter.

10. A testing apparatus, characterized in that, The device includes: The first acquisition module is used to acquire a test script, which includes multiple test items. The test script is determined based on test requirements and multiple preset functional modules, and each preset functional module is used to test the corresponding function. The parsing module is used to parse the at least one target test item in response to the selection operation of the plurality of test items, and obtain the parsing result; An execution module is used to execute the at least one target test item based on the parsing results.

11. A testing device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to implement the test method as described in any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the test method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, the test method according to any one of claims 1 to 9 is implemented.

Images