Automatic test method, device, apparatus and storage medium

Abstract

This application relates to the field of automated testing technology, and discloses an automated testing method, apparatus, device, and storage medium. The method includes: acquiring test cases, which are generated by converting test cases into test scripts, and the test scripts are generated by recording user interactive operations on the content to be tested; performing interactive operation tests on the content to be tested according to the test cases, and capturing the execution result image of the test cases at the end of the test; inputting the execution result image into a preset detection model for recognition to obtain assertion results, wherein the preset detection model is trained on sample execution result images of different sample test content and corresponding assertion result labels. This application can avoid manual judgment of assertion results by acquiring test cases, capturing the execution result image of the test cases at the end of the test cases, inputting the execution result image into a preset detection model for recognition, and obtaining assertion results, thereby reducing the manual cost of testing.

Description

Technical Field

[0001] This application relates to the field of automatic testing technology, and in particular to an automatic testing method, apparatus, device and storage medium. Background Technology

[0002] Automated testing is widely used throughout the software development lifecycle, especially in regression testing, continuous integration, and release verification for web applications, mobile applications, and enterprise systems. It replaces manual repetitive execution of test cases, improving testing efficiency. Currently, mainstream automated testing solutions typically employ the following approach: testers manually write test cases by creating scripts, encode test data within the scripts, and then manually determine the final assertion results. However, the reliance on manual judgment for assertion results leads to high manual testing costs. Summary of the Invention

[0003] The main objective of this application is to provide an automatic testing method, apparatus, device, and storage medium, which aims to solve the technical problem that the assertion results in the prior art rely on manual judgment, resulting in high labor costs for testing.

[0004] To achieve the above objectives, this application proposes an automatic testing method, the method comprising: Obtain test cases, which are generated by converting test scripts, and the test scripts are generated by recording user interactions with the content to be tested. Perform interactive operation tests on the content to be tested according to the test cases, and capture the execution result image of the test cases at the end of the test; The execution result image is input into a preset detection model for recognition to obtain assertion results. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding assertion result labels.

[0005] In one embodiment, prior to the step of obtaining test cases, the following steps are included: Record the user's interactive operations on the test content, obtain the operation sequence, event type and element location path of the interactive operations, and generate a test script; The test script is converted according to a preset mapping relationship to obtain the test cases; The step of performing interactive operation tests on the content to be tested according to the test cases includes: Execute the interactive operations in the order described in the test case; During the execution of the interactive operation, the operation position of the interactive operation is determined according to the element positioning path corresponding to the interactive operation; Based on the event type corresponding to the interactive operation, the interactive operation test is performed on the content to be tested at the operation location.

[0006] In one embodiment, the step of performing interactive operation testing on the content to be tested at the operation location according to the event type corresponding to the interactive operation includes: When the event type is an input operation type, identify and determine the type of the input item at the operation location, obtain the test data corresponding to the type of the input item, and fill the test data into the input item to perform interactive operation testing on the content to be tested; If the event type is a click operation, a click operation is performed at the operation location to perform interactive operation testing on the content to be tested; When the event type includes a click operation type and a selection operation type, a click operation is performed at the operation location to expand the drop-down list, obtain all the optional options of the drop-down list, determine the current index of the target option from all the optional options according to the current test execution round, and perform a selection operation according to the current index to perform interactive operation testing on the content to be tested.

[0007] In one embodiment, prior to the step of obtaining test cases, the method further includes: The common parameter set is classified according to the type of the input item to obtain the classification parameter set corresponding to the type of each input item; Each classification parameter set is divided according to a preset data type to obtain an initial dataset for each classification parameter set under each preset data type. The preset data types include positive test data type, boundary test data type, and abnormal test data type. Select at least one initial dataset from each of the initial datasets under the classification parameter set corresponding to the type of the input item, and construct a preset test dataset corresponding to the type of the input item. The step of obtaining the test data corresponding to the type of the input item includes: The corresponding preset test dataset is determined based on the type of the input item, and test data is randomly / sequentially selected from the preset test dataset.

[0008] In one embodiment, the step of converting the test script according to a preset mapping relationship to obtain the test cases includes: The useless event types of the interactive operations in the test script are removed, and the event types after removing the useless event types are merged to obtain the final event types; By regenerating the element location paths of interactive operations in the test script using different location generation methods, the initial location paths corresponding to each location generation method are obtained. The initial positioning paths are concatenated to obtain the final element positioning path; The test cases are obtained based on the operation sequence, the final event type, and the final element location path.

[0009] In one embodiment, the step of inputting the execution result image into a preset detection model for recognition to obtain an assertion result includes: The execution result image is input into the preset detection model for recognition to obtain preliminary recognition results. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding preliminary recognition result labels. Perform semantic recognition on the execution result image and output the semantic recognition result; Determine the semantic similarity between the preliminary identification result and the semantic identification result; If the semantic recognition result does not contain semantic contradictions, or if the similarity is less than a preset threshold, the preliminary recognition result will be used as the assertion result. In the event of semantic contradictions in the semantic recognition results, an assertion result is determined based on preset result judgment rules and the preliminary recognition results.

[0010] In one embodiment, the step of determining the assertion result based on a preset result judgment rule and the preliminary recognition result when the semantic recognition result contains a semantic contradiction includes: If there is a semantic contradiction in the semantic recognition result, update the current execution count and return to the step of performing interactive operation tests on the content to be tested according to the test case, until the current execution count reaches the preset number, and then determine the assertion result based on the occurrence count of the preliminary recognition result.

[0011] Furthermore, to achieve the above objectives, this application also proposes an automatic testing device, the device comprising: The test case acquisition module is used to acquire test cases. The test cases are generated by converting test scripts, and the test scripts are generated by recording user interaction operations on the content to be tested. The test case testing module is used to perform interactive operation tests on the content to be tested according to the test cases, and capture the execution result image of the test cases at the end of the test; The result recognition module is used to input the execution result image into a preset detection model for recognition and to obtain the assertion result. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding assertion result labels.

[0012] In addition, to achieve the above objectives, this application also proposes an automatic testing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the automatic testing method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the automatic testing method described above.

[0014] This application provides an automatic testing method, apparatus, device, and storage medium. The method includes: acquiring test cases, wherein the test cases are generated by converting test scripts, and the test scripts are generated by recording user interaction operations on the content to be tested; performing interactive operation tests on the content to be tested according to the test cases, and capturing the execution result image of the test cases at the end of the test; inputting the execution result image into a preset detection model for recognition to obtain assertion results, wherein the preset detection model is obtained by training on sample execution result images of different sample content to be tested and corresponding assertion result labels.

[0015] The automated testing method of this application obtains test cases, performs interactive operation tests on the content to be tested according to the test cases, and captures the execution result image of the test cases at the end of the test. The execution result image is then input into a preset detection model for recognition to obtain assertion results. Compared with existing assertion results that rely on manual judgment, resulting in high manual testing costs, this application can avoid manual judgment of assertion results by inputting the execution result image into a preset detection model for recognition, thereby helping to reduce the manual testing costs. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application; Figure 2 This is a flowchart illustrating the first embodiment of the automatic testing method of this application; Figure 3 This is a flowchart illustrating the second embodiment of the automatic testing method of this application; Figure 4 This is a schematic diagram illustrating the generation of the final element location path in the second embodiment of the automatic testing method of this application; Figure 5 This is a flowchart illustrating the third embodiment of the automatic testing method of this application; Figure 6 This is a schematic diagram illustrating a semantic contradiction in the third embodiment of the automatic testing method of this application; Figure 7 This is a structural block diagram of the automatic testing device of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] Reference Figure 1 , Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application.

[0022] like Figure 1As shown, the automated testing device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may be connected to a display screen; optionally, the user interface 1003 may include a standard wired interface or a wireless interface. In this application, the wired interface of the user interface 1003 may be a USB interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or non-volatile memory (NVM), such as a disk storage device. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0023] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0024] like Figure 1 As shown, the memory 1005, which is identified as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an automatic test program.

[0025] exist Figure 1 In the device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to the user equipment; the device calls the automatic test program stored in the memory 1005 through the processor 1001 and executes the steps of the automatic test method provided in the embodiments of this application.

[0026] It's important to note that automated testing is widely used throughout the software development lifecycle, particularly in regression testing, continuous integration, and release verification for web applications, mobile applications, and enterprise systems. It replaces the manual repetitive execution of test cases, improving testing efficiency. Currently, mainstream automated testing solutions typically employ the following approach: testers manually write test cases by creating scripts, encode test data within the scripts, and then manually determine the final assertion results. However, the reliance on manual judgment for assertion results leads to high manual costs in testing.

[0027] Therefore, to address the aforementioned deficiencies, this application provides an automatic testing method, apparatus, device, and storage medium. The method includes: acquiring test cases, wherein the test cases are generated by converting test scripts, and the test scripts are generated by recording user interaction operations on the content to be tested; performing interactive operation tests on the content to be tested according to the test cases, and capturing the execution result image of the test cases at the end of the test; inputting the execution result image into a preset detection model for recognition to obtain assertion results, wherein the preset detection model is obtained by training on sample execution result images of different sample content to be tested and corresponding assertion result labels.

[0028] The automated testing method of this application obtains test cases, performs interactive operation tests on the content to be tested according to the test cases, and captures the execution result image of the test cases at the end of the test. The execution result image is then input into a preset detection model for recognition to obtain assertion results. Compared with existing assertion results that rely on manual judgment, resulting in high manual testing costs, this application can avoid manual judgment of assertion results by inputting the execution result image into a preset detection model for recognition, thereby helping to reduce the manual testing costs.

[0029] For ease of understanding, the following is combined with Figures 2 to 7 The automatic testing method provided in the embodiments of this application will be described in detail.

[0030] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the automatic testing method of this application. The first embodiment of the automatic testing method of this application is presented as follows: Figure 2 As shown, in this embodiment, the method is applied to the aforementioned device, and the specific method includes: Step S10: Obtain test cases. The test cases are generated by converting test scripts, which are generated by recording user interaction with the content to be tested.

[0031] It is understood that the method of this embodiment can be applied to the above-mentioned device, which can be any device with data processing, program running and data acquisition functions, such as a computer, server, etc., and is not limited in this embodiment.

[0032] It should be noted that the test cases mentioned above can be a set of executable instruction sequences used for automated testing, such as a collection of user actions on a webpage, such as clicking buttons, entering text, and selecting drop-down lists.

[0033] It should also be noted that the test scripts mentioned above can be intermediate files that record user interactions, such as JavaScript key-value pairs (JavaScript Object Notation, JSON) structured data files generated by browser recording tools. The users mentioned above can be testers or developers performing manual operations.

[0034] It is understood that the above-mentioned content to be tested can be the software system or interface being tested, such as a web page, a mobile application interface, etc., and the above-mentioned interactive operations can be the user's actions on the above-mentioned content to be tested, such as clicking, inputting, selecting, etc.

[0035] It is also understandable that the above-mentioned recording generation can be a process of automatically capturing user interaction operations and converting them into structured data through browser built-in recording tools or third-party recording plugins, such as capturing click and input operations through Chrome DevTools Recorder and exporting them as JSON files.

[0036] In its implementation, the aforementioned automated testing device acquires a test case. This test case is obtained by converting a test script. The test script is automatically generated by the system when the user performs interactive operations on the content to be tested. In other words, the user only needs to operate the software as usual, and the device records these operations in the background, forming a test script, which is then converted into an executable test case.

[0037] Step S20: Perform interactive operation tests on the content to be tested according to the test cases, and capture the execution result image of the test cases at the end of the test.

[0038] It should be noted that the above-mentioned interactive operation test can refer to the automated process of performing simulated user behavior on the content to be tested according to the test cases, such as automatically clicking buttons, automatically entering text, and automatically selecting drop-down lists.

[0039] It should also be noted that the above execution result image can refer to an image file obtained by taking a screenshot of the current display interface of the content to be tested after the test case has been executed, such as a screenshot in portable network graphics format.

[0040] In its implementation, the device performs interactive operation tests on the content to be tested according to the acquired test cases. The device executes each interactive operation recorded in the test cases one by one, such as clicking, inputting, and selecting in sequence. Then, when all interactive operations in the test cases have been executed, the device captures a screenshot of the current display interface of the content to be tested, obtaining an execution result image. This execution result image records the visual state of the test result of the content to be tested at the end of the test, and is used for subsequent assertion judgments.

[0041] Step S30: Input the execution result image into the preset detection model for recognition to obtain the assertion result. The preset detection model is obtained by training on the sample execution result images of different sample test content and the corresponding assertion result labels.

[0042] It should be noted that the aforementioned preset detection model can refer to a pre-trained artificial intelligence model used to classify or detect objects in input images, such as a deep learning-based object detection model, specifically the YOLOv11 model. It should also be noted that the above assertion results can refer to information that determines whether the test execution meets the expected results, such as identifying the result as a category such as "success", "failure" or "error". It is understandable that the above-mentioned sample execution result image may refer to a screenshot sample with known results used to train the model, and the above-mentioned assertion result label may refer to the expected output category manually labeled corresponding to the sample execution result image, such as labeling "success" on a screenshot showing "order submitted successfully".

[0043] It can also be understood that the above training can refer to the process of using sample data and corresponding labels to adjust the model parameters through optimization algorithms, so that the model can predict the correct category or location from the input image.

[0044] In its implementation, the device uses the captured execution result image as input data and feeds it into a pre-trained preset detection model. This preset detection model performs forward inference calculations on the execution result image and outputs an assertion result. The training process of the preset detection model is as follows: The device collects multiple different sample execution result images corresponding to the test content and manually labels each sample execution result image with the corresponding assertion result label (e.g., labeled as "success", "failure", or "error"). Subsequently, the initial model is trained using these labeled sample execution result images. By continuously adjusting the model's internal parameters, the model can automatically identify and output the correct assertion result from new execution result images. After obtaining the assertion result output by the model, the device can use it to determine whether the test has passed.

[0045] This embodiment solves the technical problem of high labor costs caused by the need for manual judgment of assertion results by recording scripts and converting them into test cases, performing interactive operation tests on the content to be tested according to the test cases, capturing the execution result image at the end of the test, inputting the execution result image into a preset detection model for recognition, and obtaining the final assertion result.

[0046] Reference Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the automatic testing method of this application. Based on the first embodiment described above, the second embodiment of the automatic testing method of this application is proposed.

[0047] In order to successfully obtain test cases, in this embodiment, before step S10, the following steps are included: Step S01: Record the user's interactive operations on the content to be tested, obtain the operation sequence, event type and element location path of the interactive operations, and generate a test script.

[0048] It should be noted that the above operation sequence can refer to the order of user interaction operations in the time dimension, such as the first step being clicking the button, the second step being entering text, and the third step being clicking the OK button.

[0049] It should also be noted that the above event types can refer to specific action categories of user interaction operations, such as click, input, and select.

[0050] It is understandable that the above element positioning path can refer to the position information expression used to uniquely identify a certain interface element in the content to be tested, such as a path expression based on Extensible Markup Language (XPath) or a path expression based on Cascading Style Sheets (CSS).

[0051] In its implementation, the aforementioned device records the user's interactive operations on the content to be tested. During recording, the device acquires three key pieces of information: first, the order of each interactive operation, i.e., recording what the user did first and what they did next; second, the event type of each interactive operation, i.e., identifying whether the operation was a click, input, or selection, etc.; and third, the element location path corresponding to each interactive operation, i.e., determining how the target element of the user's operation is identified on the interface. Subsequently, the device organizes the above three pieces of information according to a preset data structure to generate a test script. This test script saves all records of user operations in structured data format.

[0052] Step S02: Convert the test script according to the preset mapping relationship to obtain the test cases.

[0053] It should be noted that the recorded test scripts (such as JSON format interaction log files) cannot be directly executed in some automated testing frameworks. Therefore, the scripts need to be converted into a sequence of instructions that the framework can recognize.

[0054] It is understandable that the aforementioned preset mapping relationship can refer to the correspondence rules between the data structure in the test script and the executable instructions of the automated testing framework. For example, mapping the "click" event type in the test script to the corresponding instruction of the test framework. Furthermore, it is understandable that the aforementioned conversion can refer to the process of regenerating the file format or data organization method of the test script into test cases that the automated testing framework can recognize and execute, according to the preset mapping relationship.

[0055] In its implementation, the device reads the generated test script and transforms it according to a pre-defined mapping relationship. Specifically, the device parses each interactive operation in the test script, finds the corresponding transformation rule based on the preset mapping relationship, and converts information such as event types and element location paths in the script into the instruction format required by the automated testing framework. After the transformation is complete, the device obtains a test case that meets the requirements of the automated testing framework and can be executed automatically.

[0056] After obtaining the above test cases, step S20 includes the following: Step S21: Execute the interactive operation according to the operation sequence of the interactive operation in the test case.

[0057] In its implementation, the device executes each interactive operation sequentially according to the order recorded in the test cases. Specifically, the device starts with the first interactive operation in the test cases and executes them in order until the last interactive operation is completed.

[0058] Step S22: During the execution of the interactive operation, the operation position of the interactive operation is determined according to the element positioning path corresponding to the interactive operation; It should be noted that the above-mentioned operation location can refer to the specific positioning information of an element in the interface to be tested on the screen or in the document, such as coordinate values, node paths, or the position of the element in the accessibility tree.

[0059] In practical implementation, during the interactive operation performed by the aforementioned device, for the currently required interactive operation, the device first obtains the element location path corresponding to the interactive operation. Next, the device searches and matches within the interface of the content to be tested based on this element location path to determine the target location of this interactive operation, i.e., the operation location. Only after determining the operation location can the device perform subsequent clicks, inputs, or other specific actions at that location.

[0060] Step S23: Perform interactive operation testing on the content to be tested at the operation location according to the event type corresponding to the interactive operation.

[0061] In its implementation, when the device performs the current interactive operation, it executes the corresponding interactive operation test at the predetermined operation location based on the event type corresponding to the interactive operation. Specifically, the device first obtains the event type of the current interactive operation (e.g., click, input, selection), and then simulates the corresponding user behavior at the operation location according to the definition of the event type. Different event types trigger different test actions, and the device completes the interactive operation test in accordance with the manner indicated by the event type.

[0062] Furthermore, in order to correctly execute the above interactive operation even when the event types are inconsistent, in this embodiment, step S23 further includes: Step S231: When the event type is an input operation type, identify and determine the type of the input item at the operation location, obtain the test data corresponding to the type of the input item, and fill the test data into the input item to perform interactive operation testing on the content to be tested.

[0063] It should be noted that the above input operation type can refer to interactive operations with the event type of input, such as entering characters in a text box or entering values ​​in a number input box.

[0064] It should also be noted that the type of input item mentioned above can refer to the category of the interface elements in the content to be tested that are used to receive user input, such as name input box, bank card number input box, amount input box, date picker, etc.

[0065] It is understandable that the test data mentioned above may refer to specific content values ​​prepared in advance according to the type of input item, used to fill in the input item to verify the system function. For example, for the name input item, the test data may be "Zhang San"; for the bank card number input item, the test data may be a string of numbers.

[0066] In its implementation, the device determines the event type when performing an interactive operation. When the event type is an input operation type, the device identifies and determines the type of the input item at the current operation location. Specifically, the device analyzes the characteristics of the input item (e.g., the label text, name attributes, etc. of the input box) using regular expression matching or contextual scene recognition technology to determine which category the input item belongs to, such as "name," "bank card number," or "amount." Next, the device obtains test data corresponding to the identified input item type. This test data can be selected from a pre-built dataset. Subsequently, the device fills the obtained test data into the input item at the operation location. Finally, the device completes the test data filling action for the input item, thereby performing the interactive operation test on the content to be tested.

[0067] Step S232: If the event type is a click operation type, perform a click operation at the operation location to perform interactive operation testing on the content to be tested.

[0068] In its implementation, when the device determines that the event type of the current interaction is a click operation, it directly performs the click operation at the determined operation location. Specifically, the device simulates the user's mouse or finger click behavior, triggering a complete click action (including pressing and releasing) on ​​the interface element corresponding to the operation location. After the click operation is completed, the device completes the interaction operation test for the content under test.

[0069] Step S233: If the event type includes a click operation type and a selection operation type, perform a click operation at the operation location to expand the drop-down box, obtain all the optional options of the drop-down box, determine the current index of the target option from all the optional options according to the current test execution round, and perform a selection operation according to the current index to perform interactive operation testing on the content to be tested.

[0070] It should be noted that the above selection operation type can refer to an interactive action used to select an item from a set of options, such as selecting an option from a drop-down list; It should also be noted that the dropdown box mentioned above can refer to a list control in the user interface that can be expanded to display multiple options, such as a custom dropdown component in Hyper Text Markup Language (HTML). Understandably, the aforementioned optional options can refer to all the options available to the user when the dropdown menu is expanded, such as "small", "medium", and "large".

[0071] It is also understandable that the current test execution round mentioned above could refer to the number of times the same test case is executed repeatedly, such as the first execution, the second execution, etc.

[0072] It should be noted that the current index of the target option mentioned above can refer to a position number determined from the array of optional options in the drop-down list according to a preset calculation rule based on the current test execution round. This position number is used to uniquely identify the position of the option to be selected in the list of optional options for this execution. The calculation rule includes at least one of the following: modulo operation rule, random selection rule, and sequential increment rule. Among them, the calculation method of the modulo operation rule is: index = (current test execution round) % (total number of optional options). For example, when the current test execution round is 0, the index is 0%3 = 0, corresponding to the first option; when the current test execution round is 1, the index is 1%3 = 1, corresponding to the second option; when the current test execution round is 3, the index is 3%3 = 0, returning to the first option, thus realizing loop traversal. The random selection rule refers to arbitrarily selecting an index value from the array of optional options. For example, an integer between 0 and (total number of optional options - 1) is generated by a random number generator as the index during each execution. The sequential increment rule means that the index is incremented sequentially with each execution. When the index reaches the total number of options, the index is reset to zero or stops incrementing in the next execution.

[0073] Understandably, the above selection operation can refer to the action of selecting an option from a drop-down list, such as clicking on a specific item in the drop-down list.

[0074] In its implementation, when the device determines that the event type of the current interaction includes both click and selection operations (e.g., operating a dropdown component requires clicking to expand before selecting an option), the device performs a click operation at the specified location to expand the dropdown. This click operation simulates the user's action of clicking on the dropdown area, displaying the list of available options. Next, the device retrieves all available options from the dropdown. The device can obtain all available options in the current dropdown by reading the Document Object Model structure or calling interfaces provided by the automated testing framework. Then, based on the current test execution round, the device determines the current index of the target option from all available options. Specifically, the device obtains the execution number of this test (e.g., the round number recorded by a step counter) and calculates the position number of the option to be selected in the available option array according to a preset rule (e.g., modulo operation: index = current round % total number of available options). Finally, the device performs a selection operation based on the current index, selecting the target option corresponding to that index. After selection, the device completes the interaction operation test for the dropdown component.

[0075] Furthermore, in order to obtain test data accurately and quickly, this embodiment includes the following step before step S10: Step S001: Classify the common parameter set according to the type of input item to obtain the classification parameter set corresponding to the type of each input item.

[0076] It should be noted that the aforementioned public parameter set can refer to a predefined set containing various test data. The data in this set is organized according to different uses and categories, such as a total set containing all name data, all bank card number data, and all amount data.

[0077] It should also be noted that the above-mentioned input item type can refer to the category of the interface element in the content to be tested that is used to receive user input, such as name input box, bank card number input box, amount input box, mobile phone number input box, etc. Understandably, the aforementioned classification parameter set can refer to a subset of data specifically serving that type of input item, obtained by filtering from the public parameter set according to a certain input item type. For example, all test data related to names in the public parameter set can be extracted to form a name-related classification parameter set.

[0078] In its implementation, before acquiring test cases, the device categorizes the common parameter set according to the type of input item. Specifically, the device reads all test data from the common parameter set and identifies the input item type corresponding to each piece of data (e.g., through pre-defined labels or fields). Subsequently, the device groups data belonging to the same input item type together, forming a category parameter set corresponding to that input item type. After classification, the device obtains multiple category parameter sets, each corresponding one-to-one with an input item type, such as a name category parameter set, a bank card number category parameter set, and an amount category parameter set. These category parameter sets will be used to dynamically provide test data for specific input items in subsequent steps.

[0079] Step S002: Divide each of the classification parameter sets according to a preset data type to obtain the initial dataset of each of the classification parameter sets under each preset data type. The preset data types include positive test data type, boundary test data type and abnormal test data type.

[0080] It should be noted that the aforementioned preset data types can refer to pre-defined standards for classifying test data, such as types classified according to the validity and boundary characteristics of the test data.

[0081] It should also be noted that the aforementioned positive test data type can refer to the data category used to verify the normal functioning of the system. This type of data conforms to the rules for the legal values ​​of the input items. For example, the positive data for the monetary input item is "100". The aforementioned boundary test data type can refer to the data category used to test the performance of the system under extreme conditions. This type of data takes the minimum, maximum, or critical value allowed for the input item. For example, the boundary data for the monetary input item is "0" or "999999". The aforementioned abnormal test data type can refer to the data category used to verify the system's ability to handle illegal inputs. This type of data does not conform to the rules for the legal values ​​of the input items. For example, the abnormal data for the monetary input item is "-50".

[0082] The aforementioned initial dataset can refer to the subset of data corresponding to each data type obtained after dividing all data in a certain classification parameter set according to a preset data type.

[0083] In its implementation, after classifying the common parameter set according to the type of input item and obtaining the classification parameter set corresponding to each input item type, the device further divides each classification parameter set according to a preset data type. The preset data types include positive test data types, boundary test data types, and abnormal test data types. Specifically, the device reads all test data from a certain classification parameter set and, based on whether each data point belongs to the positive, boundary, or abnormal category, assigns it to the corresponding initial dataset. For each classification parameter set, the device ultimately obtains three initial datasets: the initial dataset corresponding to the positive test data type, the initial dataset corresponding to the boundary test data type, and the initial dataset corresponding to the abnormal test data type. Different types of initial datasets will be used for different test scenarios: the positive dataset is used to verify normal functionality, the boundary dataset is used to test extreme conditions, and the abnormal dataset is used to verify the ability to handle illegal inputs.

[0084] Step S003: Select at least one initial dataset from each of the initial datasets under the classification parameter set corresponding to the type of the input item, and construct a preset test dataset corresponding to the type of the input item.

[0085] It should be noted that the aforementioned preset test dataset can refer to a dataset obtained by selecting at least one initial dataset (e.g., one or more of the following: positive test data type initial dataset, boundary test data type initial dataset, and anomaly test data type initial dataset) from the initial dataset under the corresponding classification parameter set for a specific input item type, and combining the data from the selected initial datasets. This preset test dataset is used to provide test data to be filled in for the corresponding input item during actual interactive operation testing.

[0086] In its implementation, the device obtains the classification parameter set corresponding to each input item type and further divides this set into initial datasets under different preset data types. For each input item type, it selects at least one initial dataset from the various initial datasets under the classification parameter set corresponding to that input item type. The device merges or associates one or more selected initial datasets to construct a preset test dataset corresponding to the type of input item. Specifically, the device can be flexibly configured according to testing needs: it can select only the positive initial dataset to construct a positive test dataset for verifying the normal function of the system; or it can simultaneously select positive, boundary, and abnormal initial datasets to construct a comprehensive test dataset to cover more comprehensive test scenarios. The constructed preset test dataset will be stored and used to quickly retrieve the corresponding test data according to the type of input item during the execution steps. Furthermore, when constructing the aforementioned test dataset, the device can select any number of test data points, for example, selecting 50 positive data points, 10 boundary data points, and 20 abnormal data points to construct a preset test dataset.

[0087] Correspondingly, step S231 includes: Step S2311: Determine the corresponding preset test dataset according to the type of the input item, and randomly / sequentially select test data from the preset test dataset.

[0088] It should be noted that the above random selection can refer to the method of randomly selecting a test data from a preset test dataset. Each selection result is independent and unpredictable. For example, a random number generator can be used to extract a data from the dataset. The above sequential selection can refer to the method of obtaining test data one by one in the order of the data in the preset test dataset. For example, the first data can be obtained the first time, the second data can be obtained the second time, and after the traversal is completed, the loop can start again from the first data.

[0089] In its implementation, when the device performs an interactive operation test and encounters an input operation type, it first determines the preset test dataset corresponding to the input item based on the type of the input item at the current operation position. Then, the device retrieves a specific test data point from this preset test dataset, either randomly or sequentially. If random selection is used, the device randomly selects a data point from the dataset using a random algorithm, potentially obtaining different test data points each time. If sequential selection is used, the device maintains a current index, retrieves the data pointed to by the current index each time, and then increments the index (setting it to zero when it reaches the dataset length), thus achieving a loop traversal. After obtaining the test data, the device fills the data into the input item, completing the assignment of test data value for that input item.

[0090] Furthermore, to clarify the process of converting the test script into the test cases, in this embodiment, step S02 includes: Step S021: Remove useless event types from the interactive operations in the test script, and merge the event types after removing the useless event types to obtain the final event types.

[0091] It should be noted that the aforementioned useless event types can refer to intermediate interactive events generated during the recording process that do not actually help the execution of automated tests or will cause repetitive operations, such as key down, key up, and mouse move; the aforementioned removal process can refer to the operation process of deleting useless event types from the event records of the test script; the aforementioned merging process can refer to the processing method of integrating multiple consecutive events of the same type that act on the same input item (such as multiple input events) into a single event; the aforementioned final event type can refer to the valid event type sequence retained after the removal of useless events and merging process, which is used to generate test cases.

[0092] In its implementation, the device first preprocesses the interactive operations in the test script. Specifically, the device iterates through all event types recorded in the test script, identifies and removes useless event types, such as deleting keydown and keyup events originally used to record continuous keystrokes, as these events do not need to be simulated in automated testing. After removing useless events, the device further checks whether there are any cases that can be merged among the remaining event types. For example, if a user enters the three characters "abc" in an input box, the recording script may generate three independent input events. The device merges these into one input event, with the event type being input operation and the data being "abc". After completing the removal and merging, the device obtains a concise and non-redundant final sequence of event types, which is used to generate test cases subsequently.

[0093] Step S022: Regenerate the element location paths of the interactive operations in the test script using different location generation methods to obtain the initial location paths corresponding to each location generation method.

[0094] It should be noted that the different positioning generation methods mentioned above can refer to various strategies or algorithms used to generate element positioning paths, such as dynamic XPath generation based on XPath functions combined with text content, generation based on Cascading Style Sheets (CSS) selectors, generation based on Accessible Rich Internet Applications (ARIA) properties, etc.; the initial positioning path mentioned above can refer to a specific element positioning expression generated by a certain positioning generation method, such as an XPath path string obtained by dynamic XPath generation.

[0095] In its implementation, besides preprocessing event types, the device also regenerates the element location path corresponding to each interactive operation in the test script. Specifically, the device employs multiple location generation methods to generate corresponding location paths for the target element of the same interactive operation. Each location generation method produces an initial location path. For example, the device may use a dynamic XPath enhancement strategy to generate an XPath path, a CSS selector generation method to generate a CSS path, and possibly an ARIA property generation method to generate another path. The device collects these initial location paths obtained through different methods for combination and optimization in subsequent steps. Generating initial location paths in parallel using multiple location generation methods can improve the success rate of element location and avoid location failures caused by relying solely on a single fragile path (such as absolute XPath) recorded during recording.

[0096] Step S023: Concatenate the initial positioning paths to obtain the final element positioning path.

[0097] It should be noted that the above concatenation can refer to combining multiple initial positioning paths in a preset order or structure to form a composite positioning expression containing information on multiple positioning methods. For example, multiple XPath paths or CSS selectors can be stored in an ordered array for the automatic testing framework to try to use in sequence when positioning elements. It should also be noted that the aforementioned final element location path may refer to the comprehensive location information obtained by concatenating the initial location paths, which is used to locate interface elements during automatic test execution. This information usually contains multiple candidate location expressions, which are tried in order of priority during execution until the target element is successfully located.

[0098] Reference Figure 4 , Figure 4 This is a schematic diagram illustrating the generation of the final element location path in the second embodiment of the automatic testing method of this application, as shown below. Figure 4As shown, the device first retrieves the XPath location path of the element in the JSON script. If the element in the JSON script contains aria text, it generates a first location path based on the aria text and the XPath function. If the element in the JSON script contains text, it generates a second location path based on the text and the XPath function. Then, it retrieves the CSS location path of the element in the JSON script to generate a third location path. The three location paths are then concatenated to generate the final element location path.

[0099] In its implementation, the device combines all initial positioning paths into an ordered set of positioning strategies according to a certain priority order (e.g., dynamic XPath paths first, CSS paths second, and the original recorded path as the last option). This set of positioning strategies is the final element positioning path. During testing, the automated testing framework attempts each positioning method sequentially according to the order in this set of positioning strategies. If any one of them succeeds, the target element is considered to have been located. This concatenated final element positioning path improves the fault tolerance and stability of element positioning.

[0100] Step S024: Obtain the test case according to the operation sequence, the final event type, and the final element location path.

[0101] In its implementation, after preprocessing the test script (including removing and merging useless events, generating and concatenating multiple location paths), the device assembles and generates a final executable test case based on the operation sequence, the final event type, and the final element location path. Specifically, the device combines the final event type and the final element location path corresponding to each interactive operation in the operation sequence to form an ordered sequence of test instructions. Each instruction includes the event type to be executed in this operation (e.g., click, input, selection) and the final element location path used to locate the target element (e.g., a concatenated multi-candidate location expression). The device arranges all instructions in the operation sequence to generate a complete test case that can be directly run in the automated testing framework.

[0102] Reference Figure 5 , Figure 5 This is a flowchart illustrating the third embodiment of the automatic testing method of this application. Based on the above embodiments, the third embodiment of the automatic testing method of this application is proposed.

[0103] Considering that the execution result image may contain multiple semantic information, and thus may contain semantic contradictions, refer to Figure 6 , Figure 6This diagram illustrates a semantic contradiction in the third embodiment of the automatic testing method of this application. If a semantic contradiction exists, continuing to use the aforementioned method of judging assertion results solely through a preset detection model may result in a failure output, even though the actual assertion result should be success. Therefore, to achieve accurate judgment of the assertion result, in this embodiment, step S30 includes: Step S31: Input the execution result image into the preset detection model for recognition to obtain preliminary recognition results. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding preliminary recognition result labels.

[0104] It should be noted that the above preliminary identification results may refer to the original identification conclusions directly output by the preset detection model after performing forward inference on the input execution result image, such as the model outputting the category labels "success", "failure" or "error" and their corresponding confidence scores; the above preliminary identification result labels may refer to the labeled categories used to train the model and corresponding to the sample execution result images, such as manually labeling "success" as a label on a screenshot showing "payment successful".

[0105] In its implementation, the device inputs the captured execution result image into a preset detection model for recognition. This model performs calculations and analysis on the input image, outputting a preliminary recognition result. Specifically, the model extracts image features using structures such as convolutional neural networks and, based on patterns learned during training, outputs whether a preset category (such as success, failure, or error) exists in the image, along with its corresponding confidence level. After obtaining the preliminary recognition result output by the model, the device uses this result for assertion judgments in subsequent steps.

[0106] The preset detection model is trained as follows: Multiple different sample execution result images corresponding to the test content are collected, and each sample image is manually labeled with a preliminary recognition result label (e.g., "success", "failure", or "error"). Subsequently, these labeled sample images are used to train the initial model, and the internal parameters of the model are continuously adjusted through optimization algorithms, enabling the model to predict the correct preliminary recognition result label from the input sample execution result images.

[0107] Step S32: Perform semantic recognition on the execution result image and output the semantic recognition result.

[0108] It should be noted that the aforementioned semantic recognition can refer to the process of extracting text information from an image and understanding its meaning. For example, text can be extracted from an image using Optical Character Recognition (OCR) technology, and then natural language understanding can be performed on the text content to determine its semantic meaning (such as success, failure, error message, etc.).

[0109] The aforementioned semantic recognition results can refer to the content output by the semantic recognition process, such as key texts and their semantic categories identified from an image, like text information such as "transaction successful" or "transaction failed".

[0110] It should also be noted that the semantic recognition result may be success, failure, or both success and failure as the semantic recognition result, such as... Figure 6 As shown, at this point, it can be considered that there is a semantic contradiction in the semantic recognition result.

[0111] In its implementation, after obtaining the execution result image, the device performs semantic recognition on it. Specifically, the device invokes a semantic recognition module (e.g., integrating an OCR engine and a natural language processing unit) to extract the text information appearing in the image and analyze the semantic meaning expressed by these characters. After completing the recognition, the device outputs the semantic recognition result. This semantic recognition result can be presented as keywords or complete sentences in text form, such as "transaction successful" or "transaction failed." This semantic recognition result will be used for subsequent comparison or fusion with the preliminary recognition result to improve the accuracy of the assertion result.

[0112] Step S33: Determine the semantic similarity between the preliminary recognition result and the semantic recognition result.

[0113] It should be noted that the aforementioned semantic similarity refers to the degree of similarity between the semantic meaning of the preliminary identification result and the semantic recognition result. It is typically quantified using a numerical value (e.g., a score between 0 and 1), with a higher value indicating greater semantic similarity. For example, if the preliminary identification result is "failure" and the semantic recognition result is "transaction failed," both representing failure-related semantics, the similarity can be determined to be 0.9. Conversely, if the preliminary identification result is "success" and the semantic recognition result is "transaction failed," their semantics are opposite, and the similarity can be determined to be 0.1 or lower.

[0114] In its implementation, after obtaining the preliminary recognition result and the semantic recognition result, the device determines the semantic similarity between the two results. Specifically, the device can use one or a combination of the following methods to calculate the semantic similarity: One method is that the device maps the preliminary recognition result (e.g., the category label "failure") to a predefined semantic vector, and at the same time converts the semantic recognition result (e.g., the text "transaction failed") into a semantic vector through a natural language processing model (such as a word embedding model), and then calculates the cosine distance between the two vectors, converting the distance into a similarity score.

[0115] Another approach involves the device using keyword matching or rule-based judgment: A predefined set of keywords for success (e.g., "success") and a set of keywords for failure (e.g., "failure") are defined. The device then checks if the keywords in the semantic recognition result match the category corresponding to the preliminary recognition result (e.g., "failure"). If they match, a high similarity score is output (e.g., 0.9); otherwise, a low similarity score is output (e.g., 0.1). After calculating the similarity score, the device uses this score in subsequent steps to determine if there are semantic contradictions, thereby deciding whether to directly adopt the preliminary recognition result as the final assertion.

[0116] Step S34: If there is no semantic contradiction in the semantic recognition result, or if the similarity is less than a preset threshold, the preliminary recognition result is used as the assertion result.

[0117] It should be noted that the aforementioned semantic contradiction can refer to the simultaneous appearance of conflicting semantic information such as success and failure in the semantic recognition result, such as... Figure 6 As shown, the text with opposite meanings, "Transaction successful" and "Image loading failed," is extracted from the same execution result image.

[0118] The aforementioned preset threshold can refer to a pre-set similarity threshold used to determine whether the preliminary recognition result and the semantic recognition result are within an acceptable range of consistency. For example, the preset threshold is 0.5. It should be noted that the condition used in this step is that the preliminary recognition result is still used as the assertion result when the similarity is less than the preset threshold. This means that when the semantic similarity is low (i.e., the difference between the two is large), the device still trusts the preliminary recognition result output by the model.

[0119] It's important to understand the following scenario: First, the semantic recognition result does not contain semantic contradictions. When the semantic recognition result does not simultaneously contain conflicting information of success and failure, it means that the execution result image only contains explicit success keywords (such as "success" or "completed") or only explicit failure keywords (such as "failure"). In this case, the preliminary recognition result output by the preset detection model based on the image will necessarily be consistent with the semantic recognition result (for example, if the image contains "success," the model will definitely output "success"). Therefore, the device directly outputs the preliminary recognition result as the assertion result.

[0120] The second scenario: When the semantic similarity is less than a preset threshold, if the semantic similarity calculated by the device is lower than a preset threshold (e.g., 0.5), the device will output the preliminary identification result as the assertion result regardless of whether there is a contradiction in the semantic recognition results. In this embodiment, this logic mainly addresses the case where the preliminary identification result is "error". Since the semantic similarity between "error" and "success" or "failure" is naturally low (e.g., if the model outputs "error" while the semantic recognition result is "payment successful", the similarity is often less than 0.5), the device directly outputs "error" as the assertion result to quickly identify abnormal system states. In this case, it is important to understand that when the preliminary identification is "error", it means that there is no detection target related to success or failure in the above result execution image. However, the semantic recognition result must output a success or failure semantic result. In this case, the preliminary identification result is "error", while the semantic recognition result is "success" or "failure", and their similarity is low. Therefore, it can be concluded that when the similarity is lower than the preset threshold, "error" can be output as the assertion result.

[0121] Step S35: If there is a semantic contradiction in the semantic recognition result, determine the assertion result according to the preset result judgment rule and the preliminary recognition result.

[0122] It should be noted that the aforementioned preset result judgment rules may refer to pre-set strategies or logic used to determine the final assertion result when there are contradictions in semantic recognition. For example, one or more of the following rules may be selected: take the preliminary recognition result as the standard, take the one with higher confidence in the semantic recognition result as the standard, or trigger manual review.

[0123] In specific implementation, when the device determines that there is a semantic contradiction in the semantic recognition result (that is, both success and failure information are identified in the semantic recognition of the same execution result image), the device does not directly use the preliminary recognition result, nor does it rely solely on the contradictory semantic recognition result. Instead, it determines the final assertion result based on the preset result judgment rules and the preliminary recognition result.

[0124] Specifically, the device invokes pre-configured result judgment rules. For example, one rule is: when semantic contradictions occur, the preliminary recognition result is trusted first (because the model has been trained on a large number of samples, and its judgment of the overall features of the image is usually better than that of text fragments). Another rule is: compare the confidence of the preliminary recognition result with the confidence of each conflicting text in the semantic recognition result, and select the one with the higher confidence as the assertion result.

[0125] Furthermore, in order to accurately output assertion results even when semantic contradictions exist in the semantic recognition results, in this embodiment, step S35 includes: Step S351: If there is a semantic contradiction in the semantic recognition result, update the current execution count and return to the step of performing interactive operation test on the content to be tested according to the test case until the current execution count reaches the preset number, and determine the assertion result based on the occurrence count of the preliminary recognition result.

[0126] It should be noted that the above update of the current execution count may refer to incrementing the count value of the current test execution by 1, which is used to record the number of times the same test case is repeatedly executed due to semantic contradictions; the above preset count may refer to a pre-set maximum repetition threshold, for example, set to 3 times, when the current execution count reaches this value, retrying will stop and the final judgment will be entered. It should also be noted that the above-mentioned determination of the assertion result based on the occurrence frequency of the preliminary identification result may refer to counting the number of occurrences of each of the preliminary identification results (e.g., "success" and "failure") during multiple retry executions, and then determining the final assertion result based on the result with the highest occurrence frequency.

[0127] In its implementation, when the device determines that the semantic recognition result contains a semantic contradiction, it does not directly determine the assertion result but instead enters a retry mechanism. Specifically, the device first updates the current execution count (e.g., increments the counter by 1). Then, the device returns to the step of performing interactive operation tests on the content to be tested according to the test case, i.e., it re-executes the test case from the beginning. Each time the execution is repeated, the device obtains a new execution result image after the new execution ends, and obtains a new preliminary recognition result and a new semantic recognition result through model recognition. The device records the preliminary recognition result obtained in each execution. The above retry process continues until the current execution count reaches a preset number (e.g., 3 times). When the preset number is reached, the device stops retrying and determines the final assertion result based on the number of occurrences of the recorded preliminary recognition results from multiple rounds. For example, the device counts the frequency of "success" and "failure" in all retry rounds and selects the result with the most occurrences as the final assertion result; if the occurrence counts are the same, the result can be output according to preset rules (e.g., selecting the last result or defaulting to failure).

[0128] In addition, refer to Figure 7 , Figure 7 This is a structural block diagram of the automatic testing device of this application. Figure 7 As shown in the embodiments of this application, an automatic testing device is also proposed, which includes: The test case acquisition module 701 is used to acquire test cases, which are generated by converting test scripts. The test scripts are generated by recording user interaction operations on the content to be tested. The test case module 702 is used to perform interactive operation tests on the content to be tested according to the test cases, and capture the execution result image of the test cases at the end of the test; The result recognition module 703 is used to input the execution result image into a preset detection model for recognition to obtain the assertion result. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding assertion result labels.

[0129] Furthermore, embodiments of this application also propose a storage medium, which is a computer-readable storage medium, storing a computer program on the storage medium. When the computer program is executed by a processor, it implements the steps of the automatic testing method described above.

[0130] The device in this embodiment acquires test cases, performs interactive operation tests on the content to be tested according to the test cases, and captures the execution result image of the test cases at the end of the test. The execution result image is then input into a preset detection model for recognition to obtain assertion results. Compared to existing methods that rely on manual judgment for assertion results, leading to high manual testing costs, this embodiment avoids manual judgment of assertion results by inputting the execution result image into a preset detection model for recognition, thereby reducing the manual testing costs.

[0131] Other embodiments or specific implementations of the automatic testing device described in this example can be found in the above-described method embodiments, and will not be repeated here.

[0132] 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 system 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 system. 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 system that includes that element.

[0133] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0134] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as a read-only memory image (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0135] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An automatic testing method, characterized in that, The method includes: Obtain test cases, which are generated by converting test scripts, and the test scripts are generated by recording user interactions with the content to be tested. Perform interactive operation tests on the content to be tested according to the test cases, and capture the execution result image of the test cases at the end of the test; The execution result image is input into a preset detection model for recognition to obtain assertion results. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding assertion result labels.

2. The method as described in claim 1, characterized in that, Before the step of obtaining test cases, the following steps are included: Record the user's interactive operations on the test content, obtain the operation sequence, event type and element location path of the interactive operations, and generate a test script; The test script is converted according to a preset mapping relationship to obtain the test cases; The step of performing interactive operation tests on the content to be tested according to the test cases includes: Execute the interactive operations in the order described in the test case; During the execution of the interactive operation, the operation position of the interactive operation is determined according to the element positioning path corresponding to the interactive operation; Based on the event type corresponding to the interactive operation, the interactive operation test is performed on the content to be tested at the operation location.

3. The method as described in claim 2, characterized in that, The step of performing interactive operation testing on the content to be tested at the operation location according to the event type corresponding to the interactive operation includes: When the event type is an input operation type, identify and determine the type of the input item at the operation location, obtain the test data corresponding to the type of the input item, and fill the test data into the input item to perform interactive operation testing on the content to be tested; If the event type is a click operation, a click operation is performed at the operation location to perform interactive operation testing on the content to be tested; When the event type includes a click operation type and a selection operation type, a click operation is performed at the operation location to expand the drop-down list, obtain all the optional options of the drop-down list, determine the current index of the target option from all the optional options according to the current test execution round, and perform a selection operation according to the current index to perform interactive operation testing on the content to be tested.

4. The method as described in claim 3, characterized in that, Before the step of obtaining test cases, the following is also included: The common parameter set is classified according to the type of the input item to obtain the classification parameter set corresponding to the type of each input item; Each classification parameter set is divided according to a preset data type to obtain an initial dataset for each classification parameter set under each preset data type. The preset data types include positive test data type, boundary test data type, and abnormal test data type. Select at least one initial dataset from each of the initial datasets under the classification parameter set corresponding to the type of the input item, and construct a preset test dataset corresponding to the type of the input item. The step of obtaining the test data corresponding to the type of the input item includes: The corresponding preset test dataset is determined based on the type of the input item, and test data is randomly / sequentially selected from the preset test dataset.

5. The method as described in claim 2, characterized in that, The step of converting the test script according to a preset mapping relationship to obtain the test cases includes: The useless event types of the interactive operations in the test script are removed, and the event types after removing the useless event types are merged to obtain the final event types; By regenerating the element location paths of interactive operations in the test script using different location generation methods, the initial location paths corresponding to each location generation method are obtained. The initial positioning paths are concatenated to obtain the final element positioning path; The test cases are obtained based on the operation sequence, the final event type, and the final element location path.

6. The method as described in claim 1, characterized in that, The step of inputting the execution result image into a preset detection model for recognition to obtain the assertion result includes: The execution result image is input into the preset detection model for recognition to obtain preliminary recognition results. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding preliminary recognition result labels. Perform semantic recognition on the execution result image and output the semantic recognition result; Determine the semantic similarity between the preliminary identification result and the semantic identification result; If the semantic recognition result does not contain semantic contradictions, or if the similarity is less than a preset threshold, the preliminary recognition result will be used as the assertion result. In the event of semantic contradictions in the semantic recognition results, an assertion result is determined based on preset result judgment rules and the preliminary recognition results.

7. The method as described in claim 6, characterized in that, The step of determining the assertion result based on a preset result judgment rule and the preliminary recognition result when there is a semantic contradiction in the semantic recognition result includes: If there is a semantic contradiction in the semantic recognition result, update the current execution count and return to the step of performing interactive operation tests on the content to be tested according to the test case until the current execution count reaches a preset number. Then, determine the assertion result based on the number of occurrences of the preliminary recognition result.

8. An automatic testing device, characterized in that, The device includes: The test case acquisition module is used to acquire test cases. The test cases are generated by converting test scripts, and the test scripts are generated by recording user interaction operations on the content to be tested. The test case testing module is used to perform interactive operation tests on the content to be tested according to the test cases, and capture the execution result image of the test cases at the end of the test; The result recognition module is used to input the execution result image into a preset detection model for recognition and to obtain the assertion result. The preset detection model is obtained by training on sample execution result images of different sample test content and corresponding assertion result labels.

9. An automatic testing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the automated testing method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of any one of the automatic testing methods as claimed in claims 1 to 7.

Images