Automated testing exception handling method and device

Abstract

An exception handling method and device for automated testing, relates to the field of artificial intelligence, and can be used in the financial field or other fields. The method includes: using an acquired test data set, reading the test data in the test data set one by one, and obtaining the result label corresponding to each test data; if it is known that the result label corresponding to the test data is failure or empty, executing the test data, and collecting the result data of the test data during the execution process; if the result data is successful, updating the result label corresponding to the test data to success; if the result data is failure, repeatedly executing the test data, collecting the execution data, until the number of repeated executions reaches a preset value or the result data of the test data is successful. The present invention improves the stability when an exception occurs in automated testing and the efficiency of handling an exception, facilitates the subsequent tracking of the cause of case failure, records the test data of successful execution, skips the successful execution record when the program is run next time, avoids repeated execution, and improves operation efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of automated testing, and in particular to an exception handling method and device for automated testing. Background Art

[0002] In automated testing, various abnormal situations often occur, resulting in the failure of test case execution. If each abnormal situation is handled separately, it is often time-consuming and labor-intensive, and various other unexpected abnormal situations may also occur. Therefore, a mechanism that can universally handle various exceptions is needed to improve the stability of automated testing and the efficiency of exception handling.

[0003] At the same time, after parameterized configuration, when multiple test cases are executed in a loop, there is no clear record of successful and failed cases. In this way, if the case execution fails, it is impossible to clearly know at which link the failure or exception occurred, and it is impossible to quickly track the case process and find the cause of the failure. At the same time, when the case execution fails, it is impossible to know which cases are successfully executed. The next time the program is re-run, all cases must be executed from the beginning. Summary of the Invention

[0004] In view of the problems existing in the prior art, the main purpose of the embodiments of the present invention is to provide an exception handling method and device for automated testing, so as to effectively solve the problems of unclear exception handling and execution information recording in automated testing.

[0005] To achieve the above objectives, an embodiment of the present invention provides an exception handling method for automated testing, the method comprising:

[0006] Using the acquired test data set, read the test data in the test data set one by one, and obtain the result label corresponding to each test data;

[0007] If it is learned that the result label corresponding to the test data is failure or empty, executing the test data and collecting result data of the test data during the execution process;

[0008] If the result data is successful, then the result label corresponding to the test data is updated to success;

[0009] If the result data is failure, the test data is repeatedly executed, and execution data corresponding to the test data is collected until the number of repeated executions reaches a preset value or the result data of the test data is success.

[0010] Optionally, in an embodiment of the present invention, executing the test data and collecting result data of the test data during the execution process includes:

[0011] Execute the test data and collect detailed data and result data of the test data during execution; wherein the detailed data includes screenshot data and page information.

[0012] Optionally, in one embodiment of the present invention, the collecting of detailed data during the execution of the test data includes:

[0013] Taking screenshots of the test data execution page according to a preset time interval to obtain screenshot data, and performing text recognition on the screenshot data to obtain text information;

[0014] Node recognition is performed on the test data execution page according to a preset time interval to obtain text attribute rules, and the text information and the text attribute rules are used as page information.

[0015] Optionally, in an embodiment of the present invention, the method further includes: inputting the execution data into a pre-established failure cause analysis model to obtain a failure cause corresponding to the test data.

[0016] Optionally, in one embodiment of the present invention, the execution data includes an error code, a response time, pop-up information, and log data.

[0017] Optionally, in one embodiment of the present invention, the failure cause analysis model is established in the following manner:

[0018] Obtain historical failure data and its corresponding failure causes and execution data, and use the historical failure data and its corresponding failure causes and execution data as training samples;

[0019] The training samples are input into the initial artificial intelligence model for model training to obtain the failure cause analysis model.

[0020] An embodiment of the present invention further provides an exception handling device for automated testing, the device comprising:

[0021] A test data module is used to use the acquired test data set to read the test data in the test data set one by one and obtain the result label corresponding to each test data;

[0022] A test execution module, configured to execute the test data if it is learned that the result tag corresponding to the test data is failure or empty, and collect result data of the test data during the execution process;

[0023] A label updating module, configured to update the result label corresponding to the test data to success if the result data is success;

[0024] The repeated execution module is used to repeatedly execute the test data if the result data is failure, and collect execution data corresponding to the test data, until the number of repeated executions reaches a preset value or the result data of the test data is success.

[0025] Optionally, in an embodiment of the present invention, the apparatus further comprises: a failure cause analysis module, configured to input the execution data into a pre-established failure cause analysis model to obtain a failure cause corresponding to the test data.

[0026] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above method when executing the program.

[0027] The present invention also provides a computer-readable storage medium storing a computer program for executing the above method.

[0028] The present invention improves the stability of automated testing when exceptions occur and the efficiency of handling exceptions by recording various information about the test data operation, making it easier to track the causes of case failures. At the same time, it records the test data of successful execution and skips the successful execution record the next time the program is run, avoiding repeated execution and improving operating efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0030] Figure 1 This is a flowchart of an exception handling method for automated testing according to an embodiment of the present invention;

[0031] Figure 2 This is a flow chart for collecting detailed data in an embodiment of the present invention;

[0032] Figure 3 A flowchart of establishing a failure cause analysis model in an embodiment of the present invention;

[0033] Figure 4 A system workflow diagram of an exception handling method using automated testing in an embodiment of the present invention;

[0034] Figure 5 This is a workflow diagram of an execution module in an embodiment of the present invention;

[0035] Figure 6This is a schematic diagram of the structure of a recording module in an embodiment of the present invention;

[0036] Figure 7 This is a schematic diagram of the structure of an exception handling device for automated testing according to an embodiment of the present invention;

[0037] Figure 8 A schematic diagram of the structure of an exception handling device for automated testing in a specific embodiment of the present invention;

[0038] Figure 9 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0039] An embodiment of the present invention provides an exception handling method and device for automated testing, which can be used in the financial field or other fields. It should be noted that the exception handling method and device for automated testing of the present invention can be used in the financial field, and can also be used in any field other than the financial field. The application field of the exception handling method and device for automated testing of the present invention is not limited.

[0040] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0041] like Figure 1 The flowchart of an exception handling method for automated testing according to an embodiment of the present invention is shown. The execution subject of the exception handling method for automated testing provided by the embodiment of the present invention includes, but is not limited to, a computer. The method shown in the figure includes:

[0042] Step S1: using the acquired test data set, reading the test data in the test data set one by one, and obtaining the result label corresponding to each test data.

[0043] The test dataset can be stored in a database. When a test case needs to be executed, the test dataset is retrieved from the database. The test dataset contains multiple test data items, each of which has a corresponding result label. Specifically, the test data items in the test dataset are read one by one, and the result label corresponding to each test data item is retrieved from the database or other storage device.

[0044] Step S2: If it is learned that the result label corresponding to the test data is failure or empty, the test data is executed, and result data of the test data during the execution process is collected.

[0045] Among them, if the result label of the test data is success, it means that the test data has been successfully run before and does not need to be run again, thereby saving time and improving efficiency.

[0046] Furthermore, the result label can be success, failure, or empty. When the test data is executed for the first time, the result label is empty.

[0047] Furthermore, if the result tag of the test data is Failed, execution of the test data begins. Specifically, configuration is performed for the test data with the Failed result tag, and after configuration, the test data is executed. Furthermore, if the result tag corresponding to the test data is empty, indicating that the test data has not been executed before, configuration is performed for execution of the test data, and after configuration, the test data is executed.

[0048] Furthermore, when executing the test data, result data of the execution process is collected. Specifically, the result data can be success or failure.

[0049] Step S3: If the result data is successful, the result label corresponding to the test data is updated to success.

[0050] If the result data is successful, it means that no exceptions occurred during the test data execution or it is consistent with the set success result. In this case, the test data is considered to be executed successfully, and the result label corresponding to the test data is updated to success.

[0051] Furthermore, the result label can be updated by directly changing it to success. Alternatively, the result label can be a sequence, and the updating process can be to sequentially add the latest result to the sequence. For example, if the result label is {Sequence Number 1: ['failed', 'failed']}, the updated result label can be {Sequence Number 1: ['failed', 'failed', 'success']}.

[0052] Step S4: If the result data is failure, repeatedly execute the test data and collect execution data corresponding to the test data until the number of repeated executions reaches a preset value or the result data of the test data is success.

[0053] If the result data is failure, it means that an abnormal error occurs during the execution of the test data or it is inconsistent with the set success result, then the test data execution is considered to have failed.

[0054] Furthermore, if the test data fails to execute, the test data is executed again, and the execution is repeated until the test data result data becomes successful, or the number of repeated executions reaches a preset value. Specifically, for example, the preset value may be 5 times. When the number of repeated executions reaches 5 times, the execution of the test data is stopped.

[0055] Furthermore, if the result data is failure, while executing the test data, execution data during the execution process is collected. Specifically, the execution data includes error code, response time, pop-up information and log data.

[0056] Furthermore, for test data that fails to execute, the program execution will be abnormally interrupted, and the test data will be judged as failed execution data. The error code and pop-up information of the page when the exception occurs can be captured, and the text attribute content of the newly added content on the page can be extracted based on OCR recognition of the page screenshot; the response time will be recorded for each test data, including failed execution data; the log is the normal log content of the operation of each test data, including failed test data.

[0057] As an embodiment of the present invention, executing the test data and collecting result data of the test data during the execution process includes: executing the test data and collecting detailed data and result data of the test data during the execution process; wherein the detailed data includes screenshot data and page information.

[0058] When executing the test data, all detailed data and result data of the test data are recorded. The detailed data is all process detailed data during the operation, and the result data is success or failure.

[0059] Furthermore, the detailed data includes screenshot data and page information. The screenshot data is obtained by regularly taking screenshots of the execution page. The page information can be obtained by performing text recognition on the screenshot data to obtain text information, or by directly performing byte recognition on the execution page.

[0060] In this embodiment, if Figure 2 As shown, the detailed data collected during the execution of the test data includes:

[0061] Step S21, taking a screenshot of the test data execution page according to a preset time interval to obtain screenshot data, and performing text recognition on the screenshot data to obtain text information;

[0062] Step S22 , performing node recognition on the test data execution page according to a preset time interval, obtaining text attribute rules, and using the text information and the text attribute rules as page information.

[0063] The preset time interval may be, for example, 1 second, and a screenshot of the test data execution page is taken every 1 second to obtain screenshot data.

[0064] Furthermore, page information refers to information on the test data execution page, which can be obtained in two ways: one is to identify nodes in the page structure and extract and save the nodes, including text attributes; the other is to use OCR technology to identify fields or other text information in the page screenshot data and save it.

[0065] As an embodiment of the present invention, the method further includes: inputting the execution data into a pre-established failure cause analysis model to obtain the failure cause corresponding to the test data.

[0066] For failed execution data, the execution data collected during the test execution process is input into a pre-established failure cause analysis model to obtain the probabilities corresponding to various failure causes. The failure cause with the highest probability is used as the failure cause for the test case.

[0067] In this embodiment, the execution data includes error code, response time, pop-up information and log data.

[0068] Among them, for test data that fails to execute, the program execution will be abnormally interrupted, and the test data will be judged as failed execution data. The error code and pop-up information of the page when the exception occurs can be captured, and the text attribute content of the newly added content on the page can be extracted based on OCR recognition of the page screenshot; the response time will be recorded for each test data, including failed execution data; the log is the normal log content of the operation of each test data, including failed test data.

[0069] In this embodiment, if Figure 3 As shown, the failure cause analysis model is established in the following way:

[0070] Step S31, obtaining historical failure data and its corresponding failure reasons and execution data, and using the historical failure data and its corresponding failure reasons and execution data as training samples;

[0071] Step S32: input the training samples into the initial artificial intelligence model for model training to obtain the failure cause analysis model.

[0072] Among them, the initial artificial intelligence model can adopt existing artificial intelligence models, such as neural network models and convolutional neural networks, and use existing failure data and failure cause data and execution data as training samples. The training samples are used to train model parameters to obtain a failure cause analysis model model, and then the actual failure data that occurred in the test is analyzed and predicted to obtain a failure cause classification.

[0073] Furthermore, the failure cause analysis model can continuously optimize parameters based on the accumulated data volume. Actual failure data is fed into the failure cause analysis model for matching and prediction, resulting in the probability of each failure cause type. The failure type with the highest probability is selected as the execution failure cause category for the test data.

[0074] like Figure 4 The figure shows a system workflow diagram of the exception handling method for automated testing in an embodiment of the present invention. In terms of exception handling, when any exception occurs, the system will shut down the application process and restart the execution of the test data, thereby universally solving various exception problems and improving the stability of the automated test program operation. In this way, there is no need to handle each exception separately, thereby improving the efficiency of exception handling.

[0075] In terms of case execution information recording, the process information and result information of the case execution will be recorded. During the execution process, the key information involved in the case will be recorded, such as key fields, the pages where the fields are located, and screenshots of the pages. This effectively records the process information of each case execution, and also records the result information of the case execution, that is, whether the case result is success or failure. For cases where execution fails, the process information and result information are combined, and automatic calculation is performed to give a classification of abnormal causes, which can effectively track the reasons for the failure of the case results and further analyze the test problems. For cases where successful execution results are recorded, if the program needs to be re-run, you can choose to skip the successful case without repeating the execution, which effectively improves the efficiency of automated testing and tracking of failure causes.

[0076] Furthermore, the system workflow is as follows:

[0077] 1. The program starts running;

[0078] 2. Read the test data set and the record module data set at the same time. If a test data result label contains "successful" test data, the result label "successful" means that the test data has been successfully run before and does not need to be run again to save time. If the test data result label is empty or all are "failed", start executing the test data;

[0079] 3. If Figure 5 As shown, after reading the test data set, the execution module takes out one of the data, configures the test data, and starts executing the test:

[0080] 3.1. If the test data runs successfully, the process can end;

[0081] 3.2. If any exception occurs during the test data execution, the test data will be re-executed from the beginning. This cycle will be repeated as long as an exception occurs. If the number of cycles exceeds the preset maximum repetition parameter N and still fails, the operation will be terminated. If the test data is successful at any time during the cycle, the process can be terminated as in 3.1.

[0082] 4. Record all detailed data and result data during the running process of the test data. The detailed data is all process detailed data during the running process, and the result data is "success" or "failure". All records are recorded in the data set; at the same time, the abnormal causes are analyzed and classified to facilitate subsequent problem analysis; among them, Figure 6 The recording module shown includes:

[0083] (1) Execution process detailed record sub-unit

[0084] Take screenshots during the data execution process. Specifically, screenshots are taken every second by default. The screenshot time interval can be customized according to needs and stored in the execution process detail record data set corresponding to the sub-unit. At the same time, the fields and content information identified during the execution process are also recorded in the database of the sub-unit. Among them, the identified content is the information in the page, and there are two methods: one is to identify nodes in the page structure, and the nodes including text attributes are extracted and saved; the other is to use OCR technology to identify fields or other text information in the page screenshot and save them. The unique indexes of these two parts of data can point to the data for quick search and matching of process detail data in the later stage.

[0085] (2) Execution result recording subunit

[0086] If no exceptions occur during the test data execution or the result is consistent with the set success result, the data execution is considered successful, and the data result label is marked as "successful" and stored in the execution result record data set. If an exception error occurs during the data execution or the result is inconsistent with the set success result, the data result label is marked as "failed" and also stored in the execution result record data set.

[0087] (3) Execution failure cause analysis subunit

[0088] For failed data, multi-dimensional data such as program error codes, response time, failure pop-up windows, and log data are captured and stored in the execution failure cause analysis data set. For failed execution data, program execution will be abnormally interrupted, and the test data is judged to be failed execution data. The error code and pop-up window information of the page when the exception occurs can be captured. This can be identified based on OCR recognition of the page screenshot or by extracting the text attributes of the newly added content on the page. The response time is recorded for each test data, including failed execution data. The log is the normal log content of each data run, including failed execution data. The existing failure cause analysis model is input for matching and prediction to obtain the probability of each failure cause type. The failure type with the highest probability is taken as the execution failure cause category of the data.

[0089] Existing AI models, such as neural network models and convolutional neural networks, first train their parameters based on existing failure data and its causes. After the model is established, actual failure data from testing is analyzed and predicted to categorize the causes of failure. Of course, the model parameters can be continuously optimized based on the accumulation of data.

[0090] 5. The loop executes all other test data in sequence and the program ends.

[0091] In a specific embodiment of the present invention, the specific process is as follows:

[0092] 1. Read the data set and obtain the following data:

[0093] {Serial number: 1, Merchant type: 'QR code merchant', Certificate type: 'Business license', Certificate number: '1234'};

[0094] {Serial number: 2, Merchant type: 'POS merchant', Certificate type: 'Organization code', Certificate number: '4321'};

[0095] {Serial number: 3, Merchant type: 'Small and micro merchants', ID type: 'ID card', ID number: '1234'}

[0096] in:

[0097] The result label in the execution result subunit corresponding to the data of sequence number 1 is {sequence number 1: ['failed', 'successful']};

[0098] The result label in the execution result subunit corresponding to the data of sequence number 2 is {sequence number 2: ['failed', 'failed', 'failed']};

[0099] There is no corresponding data for the result tag in the execution result subunit corresponding to the data of sequence number 3;

[0100] 2. Start executing each data in turn:

[0101] (1) First execute the first data {serial number: 1, merchant type: 'QR code merchant', certificate type: 'business license', certificate number: '1234'}. The result label in the execution result subunit corresponding to this data is {serial number 1: ['failed', 'successful']}. The result label of this data contains "successful", indicating that the data has been successfully run. There is no need to repeat the test record, and the next data is executed sequentially.

[0102] (2) Execute the second data {serial number: 2, merchant type: 'POS merchant', certificate type: 'organization code', certificate number: '4321'}. The result label in the execution result subunit corresponding to this data is {serial number 2: ['failed', 'failed', 'failed']}. The result labels of this data are all "failed", which means that there has been no successful operation. Then start to configure and execute this data:

[0103] 1) During the execution process, if the program does not encounter any exceptions or matches the expected results, the data is considered to have run successfully, and the data result label is changed to "success". The label is recorded in the execution result recording sub-unit. At the same time, the data and screenshots during the program execution are saved in the execution process detailed data sub-unit. After the execution is completed, the next data can be executed sequentially;

[0104] 2) If the program is judged to be abnormally interrupted or does not match the expected result, the data execution is considered unsuccessful, and the detailed data and screenshots of the running process are recorded in the detailed data of the execution process. At the same time, the error report and the abnormal situation are recorded in the execution failure cause analysis sub-unit. The unit further analyzes the abnormal code and situation and classifies the failure cause; the data is reconfigured and restarted. If it succeeds, the corresponding data is recorded and the next data is executed. If it fails, the corresponding data is recorded again and the data is re-run. If the number of failures is equal to the preset threshold and still unsuccessful, the data is skipped and the execution of the next data is prepared;

[0105] (3) Execute the third data {serial number: 3, merchant type: 'small and micro merchants', certificate type: 'identity card', certificate number: '1234'}. The result tag in the execution result subunit corresponding to the test data has no corresponding data, indicating that the test data has not been executed. Start configuring the execution of this data:

[0106] The execution process is the same as type (2), executing and recording the corresponding detailed data and result data. If successful, the execution is completed. If an exception occurs, the exception code or situation is recorded and stored in the execution failure cause analysis sub-unit for analysis and classification. If the number of failures is equal to the pre-set threshold and still unsuccessful, the test data is skipped and the execution is completed.

[0107] The present invention improves the stability of automated testing when exceptions occur and the efficiency of handling exceptions by recording various information about the test data operation, making it easier to track the causes of case failures. At the same time, it records the test data of successful execution and skips the successful execution record the next time the program is run, avoiding repeated execution and improving operating efficiency.

[0108] like Figure 7 FIG2 is a schematic diagram of the structure of an exception handling device for automated testing according to an embodiment of the present invention. The device shown in the figure includes:

[0109] The test data module 10 is configured to use the acquired test data set to read the test data in the test data set one by one and obtain a result label corresponding to each test data.

[0110] The test dataset can be stored in a database. When a test case needs to be executed, the test dataset is retrieved from the database. The test dataset contains multiple test data items, each of which has a corresponding result label. Specifically, the test data items in the test dataset are read one by one, and the result label corresponding to each test data item is retrieved from the database or other storage device.

[0111] The test execution module 20 is configured to execute the test data if it is learned that the result tag corresponding to the test data is failure or null, and collect result data of the test data during the execution process.

[0112] Among them, if the result label of the test data is success, it means that the test data has been successfully run before and does not need to be run again, thereby saving time and improving efficiency.

[0113] Furthermore, the result label can be success, failure, or empty. When the test data is executed for the first time, the result label is empty.

[0114] Furthermore, if the result tag of the test data is Failed, execution of the test data begins. Specifically, configuration is performed on the test data with the Failed result tag, and after configuration, the test data is executed. Furthermore, if the result tag corresponding to the test data is empty, indicating that the test data has not been executed, configuration is performed on the test data, and after configuration, the test data is executed.

[0115] Furthermore, when executing the test data, result data of the execution process is collected. Specifically, the result data can be success or failure.

[0116] The label updating module 30 is configured to update the result label corresponding to the test data to success if the result data is success.

[0117] If the result data is successful, it means that no exceptions occurred during the test data execution or it is consistent with the set success result. In this case, the test data is considered to be executed successfully, and the result label corresponding to the test data is updated to success.

[0118] Furthermore, the result label can be updated by directly changing it to success. Alternatively, the result label can be a sequence, and the updating process can be to sequentially add the latest result to the sequence. For example, if the result label is {Sequence Number 1: ['failed', 'failed']}, the updated result label can be {Sequence Number 1: ['failed', 'failed', 'success']}.

[0119] The re-execution module 40 is configured to re-execute the test data if the result data indicates failure, and collect execution data corresponding to the test data, until the number of re-executions reaches a preset value or the result data of the test data indicates success.

[0120] If the result data is failure, it means that an abnormal error occurs during the execution of the test data or it is inconsistent with the set success result, then the test data execution is considered to have failed.

[0121] Furthermore, if the test data fails to execute, the test data is executed again, and the execution is repeated until the test data result data becomes successful, or the number of repeated executions reaches a preset value. Specifically, for example, the preset value may be 5 times. When the number of repeated executions reaches 5 times, the execution of the test data is stopped.

[0122] Furthermore, if the result data is failure, while executing the test data, execution data during the execution process is collected. Specifically, the execution data includes error code, response time, pop-up information and log data.

[0123] Furthermore, for test data that fails to execute, the program execution will be abnormally interrupted, and the test data will be judged as failed execution data. The error code and pop-up information of the page when the exception occurs can be captured, and the text attribute content of the newly added content on the page can be extracted based on OCR recognition of the page screenshot; the response time will be recorded for each test data, including failed execution data; the log is the normal log content of the operation of each test data, including failed test data.

[0124] In this embodiment, if Figure 8 As shown, the apparatus further includes: a failure cause analysis module 50, configured to input the execution data into a pre-established failure cause analysis model to obtain the failure cause corresponding to the test data.

[0125] For failed execution data, the execution data collected during the test execution process is input into a pre-established failure cause analysis model to obtain the probabilities corresponding to various failure causes. The failure cause with the highest probability is used as the failure cause for the test case.

[0126] Based on the same application concept as the aforementioned exception handling method for automated testing, the present invention also provides the aforementioned exception handling device for automated testing. Because the principles for solving problems in the exception handling device for automated testing are similar to those in the exception handling method for automated testing, the implementation of the exception handling device for automated testing can be referenced to the implementation of the exception handling method for automated testing, and any repetitions will not be repeated.

[0127] The present invention improves the stability of automated testing when exceptions occur and the efficiency of handling exceptions by recording various information about the test data operation, making it easier to track the causes of case failures. At the same time, it records the test data of successful execution and skips the successful execution record the next time the program is run, avoiding repeated execution and improving operating efficiency.

[0128] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above method when executing the program.

[0129] The present invention also provides a computer-readable storage medium storing a computer program for executing the above method.

[0130] like Figure 9 As shown, the electronic device 600 may further include: a communication module 110, an input unit 120, an audio processing unit 130, a display 160, and a power supply 170. It is worth noting that the electronic device 600 does not necessarily have to include Figure 9 In addition, the electronic device 600 may also include all components shown in Figure 9 For components not shown, reference may be made to the prior art.

[0131] like Figure 9 As shown, the central processing unit 100 is sometimes also referred to as a controller or an operation control unit, and may include a microprocessor or other processor device and / or logic device. The central processing unit 100 receives inputs and controls the operations of various components of the electronic device 600 .

[0132] Memory 140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information and may also store programs that execute the relevant information. The CPU 100 may execute the programs stored in memory 140 to implement information storage or processing.

[0133] The input unit 120 provides input to the CPU 100. The input unit 120 may be, for example, a keypad or touch input device. The power supply 170 is used to provide power to the electronic device 600. The display 160 is used to display objects such as images and text. The display may be, for example, an LCD display, but is not limited thereto.

[0134] The memory 140 may be a solid-state memory, such as a read-only memory (ROM), a random access memory (RAM), or a SIM card. Alternatively, it may be a memory that retains information even when power is off, can be selectively erased, and is provided with more data. Examples of such memory are sometimes referred to as EPROMs. The memory 140 may also be some other type of device. The memory 140 includes a buffer memory 141 (sometimes referred to as a buffer). The memory 140 may include an application / function storage unit 142 for storing application programs and function programs or processes for executing the operations of the electronic device 600 via the central processing unit 100.

[0135] The memory 140 may also include a data storage unit 143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 144 of the memory 140 may include various driver programs for communication functions of the electronic device and / or for executing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0136] The communication module 110 is a transmitter / receiver 110 that transmits and receives signals via an antenna 111. The communication module (transmitter / receiver) 110 is coupled to the central processor 100 to provide input signals and receive output signals, which may be the same as in a conventional mobile communication terminal.

[0137] Based on different communication technologies, multiple communication modules 110 may be provided in the same electronic device, such as a cellular network module, a Bluetooth module, and / or a wireless local area network module. The communication module (transmitter / receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide audio output via the speaker 131 and receive audio input from the microphone 132, thereby implementing common telecommunication functions. The audio processor 130 may include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor 130 is also coupled to the central processing unit 100, enabling local recording via the microphone 132 and playback of stored audio via the speaker 131.

[0138] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0139] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0140] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0141] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The steps for the function specified in one or more boxes.

[0142] Specific embodiments are used in the present invention to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the contents of this specification should not be understood as limiting the present invention.

Claims

1. An exception handling method for automated testing, characterized in that: The method comprises: Using the acquired test data set, reading the test data in the test data set one by one, and obtaining the result label corresponding to each test data; If it is learned that the result tag corresponding to the test data is failure or empty, executing the test data and collecting result data of the test data during the execution process; If the result data is successful, the result label corresponding to the test data is updated to success, or the latest result is sequentially added to the result label sequence; If the result data is failure, the test data is repeatedly executed, and execution data corresponding to the test data is collected, until the number of repeated executions reaches a preset value or the result data of the test data is success; The executing the test data and collecting result data of the test data during the execution process includes: Execute the test data, and collect detailed data and result data of the test data during execution; wherein the detailed data includes screenshot data and page information; The detailed data collected during the execution of the test data includes: Taking a screenshot of the test data execution page according to a preset time interval to obtain screenshot data, and performing text recognition on the screenshot data to obtain text information; Node recognition is performed on the test data execution page according to a preset time interval to obtain text attribute rules, and the text information and the text attribute rules are used as page information.

2. The method according to claim 1, characterized in that The method further includes: inputting the execution data into a pre-established failure cause analysis model to obtain the failure cause corresponding to the test data.

3. The method according to claim 2, characterized in that The execution data includes error code, response time, pop-up information and log data.

4. The method according to claim 2, characterized in that: The failure cause analysis model is established in the following way: Acquire historical failure data and its corresponding failure causes and execution data, and use the historical failure data and its corresponding failure causes and execution data as training samples; The training samples are input into the initial artificial intelligence model for model training to obtain the failure cause analysis model.

5. An exception handling device for automated testing, characterized in that: The device comprises: A test data module is used to use the acquired test data set to read the test data in the test data set one by one, and obtain the result label corresponding to each test data; A test execution module, configured to execute the test data if it is known that the result tag corresponding to the test data is failed or empty, and collect result data of the test data during the execution process; A label update module, used for updating the result label corresponding to the test data to success if the result data is success, or sequentially adding the latest result in the result label sequence; A repeated execution module, used for repeatedly executing the test data if the result data is failure, and collecting execution data corresponding to the test data, until the number of repeated executions reaches a preset value or the result data of the test data is success; The test execution module is further used to execute the test data and collect detailed data and result data of the test data during execution; wherein the detailed data includes screenshot data and page information; Among them, the test execution module is also used to take a screenshot of the test data execution page according to a preset time interval to obtain screenshot data, and perform text recognition on the screenshot data to obtain text information; perform node recognition on the test data execution page according to the preset time interval to obtain text attribute rules, and use the text information and the text attribute rules as page information.

6. The device according to claim 5, characterized in that The device further comprises: a failure cause analysis module, which is used to input the execution data into a pre-established failure cause analysis model to obtain the failure cause corresponding to the test data.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 4 is implemented.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program for executing the method according to any one of claims 1 to 4.

Images