Data processing method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The invention provides a data processing method and device, electronic equipment, a computer program product and a computer readable storage medium. The method comprises the steps of obtaining sample data of a to-be-tested page, wherein the sample data is used for testing any display state of the to-be-tested page; a target test set of the to-be-tested page is generated based on the sample data, the target test set comprises at least two pieces of test data and an expected display state corresponding to each piece of test data, and the at least two pieces of test data are used for testing each display state of the to-be-tested page; obtaining an updated page code obtained by updating the to-be-tested page, and determining each updated display state of the to-be-tested page based on the updated page code and the at least two pieces of test data; and determining a test result of the updated page code based on each updated display state and each expected display state. Through the data processing method and device, the data processing cost can be reduced, and the data processing efficiency can be improved.

Description

Technical Field

[0001] This application relates to information technology, and more particularly to a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] Unit testing is used to test the front-end, treating a unit (referring to a function, component, page, etc.) as the smallest test. In related technologies, unit testing is implemented by manually writing test cases. After inputting the test cases into the unit, the unit's code is executed, and the output is compared to the expected output. If they match, the test passes. However, for front-end pages or component units, enumerating all states of the front-end page through test cases requires not only a deep understanding of the unit's business logic but also the manual writing of a large number of test cases, resulting in high labor costs and low efficiency. Summary of the Invention

[0003] This application provides a data processing method, apparatus, computer-readable storage medium, and computer program product, which can reduce the cost of data processing and improve the efficiency of data processing.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a data processing method, the method comprising:

[0006] Obtain sample data of the page to be tested, the sample data being used to test any display state of the page to be tested; generate a target test set for the page to be tested based on the sample data, the target test set including at least two test data and an expected display state corresponding to each test data, the at least two test data being used to test each display state of the page to be tested; obtain the updated page code obtained by updating the page to be tested, and determine each updated display state of the page to be tested based on the updated page code and the at least two test data; determine the test result of the updated page code based on each updated display state and each expected display state.

[0007] This application provides a data processing apparatus, including:

[0008] The acquisition module is used to acquire sample data of the page to be tested, the sample data being used to test any display state of the page to be tested; the generation module is used to generate a target test set of the page to be tested based on the sample data, the target test set including at least two test data and an expected display state corresponding to each test data, the at least two test data being used to test each display state of the page to be tested; the acquisition module is also used to acquire updated page code obtained by updating the page to be tested, and to determine each updated display state of the page to be tested based on the updated page code and the at least two test data; the determination module is used to determine the test result of the updated page code based on each updated display state and each expected display state.

[0009] This application provides an electronic device, the electronic device comprising:

[0010] Memory is used to store executable instructions or computer programs.

[0011] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method provided in the embodiments of this application.

[0012] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the data processing method provided in this application when executed by a processor.

[0013] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the data processing method provided in this application.

[0014] The embodiments of this application have the following beneficial effects:

[0015] The process involves acquiring sample data from the page under test and generating a target test set based on this data. The target test set includes at least two test cases and the expected display state for each test case. These at least two test cases can test every display state of the page under test. This automatic generation of the target test set from sample data improves the efficiency and accuracy of its generation, thereby enhancing the efficiency and accuracy of testing the page under test using the target test set. When the code of the page under test is updated, the updated page code and at least two test cases are used to determine each updated display state. Each updated display state is compared with each expected display state to determine whether the updated page code affects other code logic on the page under test. This improves the efficiency and accuracy of detecting updated page code, prevents code anomalies from causing online issues, and enhances the security and stability of the page under test. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the structure of the data processing system 100 provided in the embodiments of this application;

[0017] Figure 2A This is a schematic diagram of the structure of the server 200 provided in the embodiments of this application.

[0018] Figure 2B This is a schematic diagram of the structure of the terminal 400 provided in the embodiments of this application;

[0019] Figure 3A This is a flowchart illustrating the data processing method provided in an embodiment of this application;

[0020] Figure 3B This is a schematic diagram of the process for generating the target test set provided in an embodiment of this application;

[0021] Figure 3C This is a schematic diagram of the process for generating test data provided in an embodiment of this application;

[0022] Figure 3D This is another schematic diagram of the process for generating the target test set provided in an embodiment of this application;

[0023] Figure 4 This application provides a flowchart illustrating the page code testing process in its embodiments;

[0024] Figure 5 This is another schematic diagram of the process for generating the target test set provided in the embodiments of this application;

[0025] Figure 6 This is another schematic diagram of the process for generating test data provided in the embodiments of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

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

[0028] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0029] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

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

[0032] 1) Unit testing: Part of the software testing process, which involves checking and verifying the smallest testable units in the software to ensure that they can perform their intended functions correctly.

[0033] 2) Test data: Data used to verify the correctness of a single function or module. It provides input to the unit being tested (e.g., function, method, object) and checks whether the unit's output meets expectations.

[0034] 3) Display Status: The different appearances and behaviors of page elements in a webpage or application under different operations or conditions. In this embodiment, display status refers to the output obtained after inputting test data into the unit under test. Testers use the test data as input and then check whether the display status of the software meets expectations to ensure that the software's behavior and interface work as designed.

[0035] 4) Primitive Data Types: Also known as primitive data types, these are the simplest data types in programming languages. The primitive data types in this application include: Number: used to represent integers and real numbers; String: used to represent and store text data, typically an ordered collection of characters, which can be letters, numbers, punctuation marks, spaces, and other special characters; Boolean: used to represent logical values, usually with only two values: true and false; Null: representing a value without any value or without a valid data type; Undefined: used to represent a variable that has been declared but not assigned a value, etc.

[0036] 5) Complex or Composite data types: These are relative to primitive data types and typically contain values ​​of multiple primitive or other complex data types, used to construct more complex data structures and models. Complex data types in this application include: object types, array types, etc.

[0037] 6) get_Random function: A user-defined function in a specific programming language that randomly selects one data item from multiple data items.

[0038] In related technologies, testing of the test page relies on manually writing test cases for each unit. Taking the test page as the display interface of an e-commerce platform as an example, multiple products share some basic layout and design elements, but these products display different styles depending on their type, brand, promotional status, etc., resulting in multiple display states for the test page. If modifications are made to the test page, such as adding a new label before the product title, this change may affect the layout and style of the product display. To check whether this change affects the display of all products, testers need to manually generate test cases to check the display of each product in different states to ensure that the added label has not introduced any layout problems or functional errors. This process relies on the tester's memory and attention, resulting in high manual costs, low efficiency, and the potential for errors due to oversight when manually generating large amounts of data.

[0039] This application provides a data processing method, apparatus, device, computer-readable storage medium, and computer program product, which can reduce the cost of data processing and improve the efficiency of data processing. The following describes exemplary applications of the electronic devices provided in this application. The devices provided in this application can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and vehicle terminals, or as servers. The following will describe exemplary applications when the device is implemented as a terminal.

[0040] See Figure 1 , Figure 1 This is a schematic diagram of the structure of the data processing system 100 provided in the embodiment of this application. The terminal 400 is connected to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0041] Terminal 400 is used to display the page to be tested on the graphical interface 401. The page to be tested has multiple different display states on the graphical interface 401. The user inputs sample data of the page to be tested into the terminal 400, and then the terminal 400 acquires the sample data and generates a target test set for the page to be tested based on the sample data. The target test set includes at least two test data and the expected display state corresponding to each test data. When the page to be tested is updated, the terminal 400 acquires the updated page code, determines each updated display state of the page to be tested based on the updated page code and at least two test data, determines the test result of the updated page code based on each updated display state and each expected display state, and then displays the test result on the graphical interface 401 of the terminal 400.

[0042] Alternatively, the user inputs sample data of the page to be tested on terminal 400. After obtaining the sample data, terminal 400 sends it to the server via network 300. Server 200 obtains the sample data and generates a target test set for the page to be tested based on it. The target test set includes at least two test data and the expected display state corresponding to each test data. The at least two test data are used to test each display state of the page to be tested. When the page to be tested is updated, server 200 obtains the updated page code. Based on the updated page code and at least two test data, it determines each updated display state of the page to be tested. Based on each updated display state and each expected display state, it determines the test result of the updated page code. Then, the server sends the test results to terminal 400 and displays the test results on the graphical interface 401 of terminal 400.

[0043] Taking the server mentioned above as an example, which is the electronic device used for data processing, see [link to relevant documentation]. Figure 2A , Figure 2A This is a schematic diagram of the structure of the server 200 provided in the embodiments of this application. Figure 2A The server 200 shown includes at least one processor 210, memory 230, and at least one network interface 220. The various components of server 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2A The general labeled all buses as Bus System 240.

[0044] The processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0045] The memory 230 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 230 may optionally include one or more storage devices physically located away from the processor 210.

[0046] The memory 230 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 230 described in this application embodiment is intended to include any suitable type of memory.

[0047] In some embodiments, memory 230 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0048] Operating system 231 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0049] The network communication module 232 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including Bluetooth, WiFi, and Universal Serial Bus (USB).

[0050] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2A A data query device 233 stored in memory 230 is shown. This device can be software in the form of programs or plug-ins, and includes the following software modules: an acquisition module 2331, a generation module 2332, and a determination module 2333. These modules are logically related and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0051] Taking the aforementioned terminal as an example of an electronic device based on data processing, see [link to relevant documentation]. Figure 2B , Figure 2B This is a schematic diagram of the structure of the terminal 400 provided in the embodiment of this application. Figure 2B The terminal 400 shown includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the terminal 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2B The general labeled all buses as Bus System 440.

[0052] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0053] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0054] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0055] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0056] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0057] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0058] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0059] Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 (e.g., a display screen, a speaker, etc.) associated with user interface 430;

[0060] The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0061] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2B A data processing device 455 stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: an acquisition module 4551, a generation module 4552, and a determination module 4553. These modules are logically linked and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0062] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the data processing method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0063] The data processing method provided in this application will be described in conjunction with exemplary applications and implementations of the terminal provided in the embodiments of this application.

[0064] The data processing method provided in the embodiments of this application will be described below. As mentioned above, the electronic device implementing the data processing method of the embodiments of this application can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0065] It should be noted that the data processing examples below are illustrated using a front-end page in an e-commerce scenario as the test page. Those skilled in the art can apply the data processing method provided in the embodiments of this application to data processing in other scenarios based on their understanding of the following text.

[0066] See Figure 3A , Figure 3A This is a flowchart illustrating the data processing method provided in the embodiments of this application, which will be combined with... Figure 3A The steps shown are explained.

[0067] In step 101, sample data of the page to be tested is obtained.

[0068] Here, the page to be tested involves a crucial aspect of front-end development. A page to be tested typically refers to the front-end page of the unit to be tested, or simply a part of that page. These pages will present various display states under different usage scenarios and conditions to adapt to different user needs and business logic. The display state refers to the visual presentation and interactive state of the page to be tested, including the displayed information, layout, colors, fonts, images, animation effects, and the page's responses or prompts when users click, scroll, or input. Taking e-commerce as an example, the page to be tested specifically refers to various web pages or page components within an e-commerce platform. These pages provide users with rich online shopping functions, such as browsing products, placing orders, and viewing orders. Within these pages, each product will exhibit different display states depending on different market strategies and user types. For example, the display state of a product will significantly differ when participating in a discount promotion, during normal sales, when pushed to member users, and when pushed to non-member users. This diversity results in the page to be tested having multiple different display states. In this process, sample data refers to test data input by users to test a specific display state of the page under test. Specifically, by inputting sample data into the code of the page under test and executing the code, the display state of the page under test can be output under any given condition. Taking a product promotion scenario as an example, sample data can help us test the display state of the page under test during a promotional activity. Sample data can be divided into two types: basic data and complex data. Basic data includes common numeric, string, boolean, null, and undefined types. These data types are simple, clear, and easy to understand and manipulate. Complex data, on the other hand, is divided into object types and array types. This type of data contains multiple basic and complex data, enabling a more comprehensive simulation of various real-world scenarios.

[0069] In step 102, a target test set for the page to be tested is generated based on the sample data.

[0070] Here, the target test set includes at least two test data sets and the expected display state corresponding to each test data set. Each test data set and its corresponding expected display state can constitute a test case. Test data can be understood as data generated with reference to sample data, similar in characteristics and properties to the sample data, used to simulate user input. Each test data set serves the same purpose as the sample data, testing a display state of the page under test. At least two test data sets in the target test set can test every display state of the page under test. It should be noted that the test data included in the target test set can determine all display states of the page under test, or all important display states, and can be pre-defined based on the actual application scenario and testing requirements. The number of expected display states is the same as the number of test data sets. Since the test data included in the target test set can enumerate all display states of the page under test, the corresponding expected display states included in the target test set cover all display states of the page under test. The expected display state is the standard output result of the test data, used to characterize the normal display state that the page under test should have under the expected state. For example, if test data A is used to test the page display state when pushing products to members, then the expected display state B corresponding to test data A is the page display state when pushing products to members when the page to be tested is running normally as expected.

[0071] In some embodiments, see Figure 3B Step 102 can be achieved through steps 1021 to 1024, as explained below:

[0072] In step 1021, test data corresponding to the sample data is generated.

[0073] Here, test data refers to a set of data similar to or analogous to sample data in characteristics and properties, generated during software testing using specific methods or algorithms. The purpose of test data is to simulate user input behavior in a real-world environment, thereby verifying and validating the functionality, performance, and stability of the software system during testing. The generation of test data needs to reference the structure and characteristics of the sample data to ensure that the generated data is consistent with the sample data in function and form, while also covering situations not explicitly included in the sample data. In some embodiments, see... Figure 3C Test data can be generated through steps 211 to 213, as explained below:

[0074] In step 211, the first data type of the sample data is determined.

[0075] Here, the first data type is the data type of the sample data, which includes: numeric type, string type, boolean type, empty type, undefined type, object type, and array type. The first data type can be any one of these data types.

[0076] In step 212, when the first data type belongs to the first preset type, test data is generated based on the first data type.

[0077] Here, the first preset type corresponds to basic types, including: numeric, string, boolean, null, and undefined types. When the first data type belongs to any of the first preset types, a random basic data type generator generates basic data of the first data type as test data. For example, if the first data type is numeric, then randomly generated numeric data is used as test data.

[0078] In step 213, when the first data type belongs to the second preset type, the multiple first subtypes included in the first data type are determined, and test data is generated based on the multiple first subtypes.

[0079] Here, the second preset type corresponds to complex types, including object types and array types. Since complex data contains multiple basic or complex data, these data often contain nested structures and may be composed of multiple data types. Therefore, to generate test data corresponding to the sample data, a recursive method is needed to process this complex data. This process starts from the outermost layer of complex data and gradually delves into the internal structure of the data through continuous recursive calls. Therefore, the first subtype refers to the data types of the multiple basic or complex data included in the complex data. When determining the first subtype, the first data type needs to be parsed layer by layer to obtain multiple first subtypes included in the first data type. For example, if the first data type includes: object type, number type, and string type; then the first subtypes are: object type, number type, and string type. Then, based on each subtype, recursive steps 212 and 213 are repeated to generate test data.

[0080] In some embodiments, the recursive process of generating test data based on multiple first subtypes specifically includes:

[0081] For each first subtype, if the first subtype belongs to a first preset type, basic data for the first subtype is generated as first candidate data. If the first subtype belongs to a second preset type, the first subtype is analyzed to determine the multiple second subtypes it includes. If every second subtype belongs to the first preset type, basic data for each second subtype is generated as second candidate data. Then, the first and second candidate data are combined according to the data structure of the sample data to form test data. If the second subtype still belongs to the second preset type, the analysis continues to obtain the third subtype, and so on, until every data type belongs to the first preset type. Then, multiple candidate data are generated, and these candidate data are gradually combined in the reverse direction of the recursive process to form data with the same structure as the sample data as test data.

[0082] For example, sample data can be schematically represented as: [object type (numeric type + string type) + numeric type]. Then, the first data type belongs to the second preset type, the first subtype includes: object type and numeric type, and the second subtype includes: numeric type and string type.

[0083] In some possible implementations, the above recursive process can be achieved using a recursive function. In some embodiments, a recursive function is obtained that can traverse every element in the sample data. If the recursion reaches a complex data type, the function will call itself (recursively call) to delve deeper into the next level of data structure. When the recursive call reaches the innermost level, i.e., the basic data, recursion will cease. Instead, a random basic data type generator is used to generate the corresponding basic data. These generators generate random values ​​based on basic data types (such as integers, floating-point numbers, strings, booleans, etc.). This generated basic data will replace the original sample data to simulate the sample data. In each level of recursion, once the basic data has been generated and used to simulate the sample data, the recursive function will return to the previous level with the new data to continue the next simulation. After the entire recursive process is complete, an integrity check can be performed to ensure that all complex data has been recursively traversed and all basic data has been generated and used to simulate user input, thus obtaining test data.

[0084] In this embodiment, a first data type of the sample data is first determined. When the first data type belongs to a first preset type, test data is directly generated based on the first data type. When the first data type belongs to a second preset type, multiple first subtypes included in the first data type are first determined. For each first subtype, if the first subtype belongs to the first preset type, first candidate data is generated based on the first subtype; if the first subtype belongs to the second preset type, multiple second subtypes included in the first subtype are determined until each second subtype is a first preset type, and then second candidate data is generated based on each second subtype. Then, test data is determined based on the first candidate data and the second candidate data. In this way, by continuously recursively calling the first data type of the sample data until the recursion reaches the basic data, the corresponding basic data is generated, thereby simulating user input. Therefore, this embodiment can achieve random generation of complex data and basic data, further improving the automation level of data processing, thereby reducing the cost of data processing and improving the efficiency of data processing.

[0085] See also Figure 3B In step 1022, the first page code of the page to be tested in the expected display state is obtained, and the expected display state corresponding to the test data is determined based on the first page code and the test data.

[0086] Here, when the test page runs the first page code, it will display a state consistent with its intended design. This display state is predefined by the designer based on user needs and user experience goals, and it includes various aspects such as the page structure, colors, fonts, and images. When the first page code is executed correctly, the test page should accurately reflect the expected display state, thus ensuring correct page display. Specifically, the test data is used as input data for the first page code, and the output obtained after executing the first page code is the expected display state of the test page.

[0087] In step 1023, a candidate test set is generated based on the test data and the expected display state.

[0088] Here, if this is the first time test data and expected display states are generated, then the test data and expected display states are added to an empty set as a candidate test set. That is, the candidate test set only includes the test data and expected display states generated the first time. If this is not the first time test data and expected display states have been generated, and historical candidate test sets have been created, then the historical candidate test sets need to be obtained first. These historical candidate test sets include all previously generated test data and expected display states. The test data and expected display states generated this time are then added to these historical candidate test sets to obtain the final candidate test set. Therefore, each generated candidate test set includes all previously generated test data and expected display states.

[0089] In some possible implementations, candidate test sets can be generated manually. This is because test data is generated randomly, and this randomness may lead to the generation of invalid or unreasonable data. This data not only does not help the test but may also introduce noise, interfering with the accuracy of the test results. Through manual intervention, test engineers can remove this invalid data, improving the quality of the test data and thus increasing the reliability of the test. Furthermore, a large amount of test data needs to be stored on servers or local storage devices. If the candidate test set contains a large amount of duplicate or invalid data, it will consume valuable storage space. Manual intervention can filter out valuable test data, reducing the number of invalid data in the candidate test set, thereby saving storage space and reducing storage costs.

[0090] In some possible implementations, each time test data and expected display state are generated, the historical candidate test set is first retrieved to determine whether the currently generated test data and expected display state are already included in the historical candidate test set. If the currently generated test data and expected display state are already included in the historical candidate test set, then the currently generated test data and expected display state will not be added to the historical candidate test set, and the historical candidate test set will be directly determined as the candidate test set for this generation.

[0091] In step 1024, the target test set is determined based on the candidate test set.

[0092] Here, to ensure that the final generated target test set can enumerate all display states of the page under test, it is necessary to determine the display state coverage of the candidate test sets for the page under test, and generate the target test set based on the display state coverage. In some embodiments, see [link to relevant documentation]. Figure 3D Step 1024 can be achieved through steps 241 to 244, as explained below:

[0093] In step 241, the display state coverage of the candidate test set for the page to be tested is determined.

[0094] Here, display state coverage is determined by the ratio of the display states that can be enumerated by the test data to all display states of the page under test. Display state coverage is between 0 and 1. The closer the display state coverage is to 1, the more display states the test data can enumerate. When the display state coverage reaches 1, it means that the candidate test set can enumerate every display state that needs to be tested on the page under test.

[0095] This involves pre-setting a corresponding preset coverage rate based on actual needs, such as 0.5%, 0.7%, or 85%. When determining the display state coverage rate, the relationship between the display state coverage rate and the expected coverage rate is compared. If the display state coverage rate is greater than the preset coverage rate, it indicates that the display states that the test data can enumerate have met the expected standard, and therefore the candidate test set can be directly determined as the target test set. If the display state coverage rate is less than or equal to the preset coverage rate, proceed to the next step. Figure 3D Proceed to steps 242 to 245.

[0096] In step 242, the next test data corresponding to the sample data is generated based on the sample data.

[0097] Here, when the display state coverage is less than or equal to the preset coverage, it means that there is not enough test data in the candidate test set. Therefore, it is necessary to generate the next test data to supplement the candidate test set, thereby improving the display state coverage of the candidate test set.

[0098] In step 243, based on the first page code and the next test data, the next expected display state corresponding to the next test data is determined.

[0099] Here, the next test data is used as the input data for the code on the first page. Then, the code on the first page is executed, and the output result is the next expected display state of the next test page.

[0100] In step 244, the next test data and the next expected display state are added to the candidate test set to obtain a new candidate test set.

[0101] Here, a new candidate test set is obtained by adding the next test data and the next expected display state to the candidate test set. The new candidate test set includes not only all the previously generated test data and expected display states, but also the latest generated next test data and the next expected display state.

[0102] In step 245, the target test set is determined based on the new candidate test set.

[0103] Here, for the new candidate test set, the display state coverage of the page to be tested is redefined. If the display state coverage of the new candidate test set is greater than the preset coverage, the new candidate test set is designated as the target test set. If the display state coverage of the new candidate test set still does not reach the preset coverage, steps 242 to 245 are repeated until the display state coverage of the latest generated candidate test set reaches the preset coverage, at which point this latest generated candidate test set is designated as the target test set.

[0104] In this embodiment, the display state coverage of the candidate test set for the page under test is determined. When the display state coverage is greater than a preset coverage, the candidate test set is determined as the target test set. When the display state coverage is less than or equal to the preset coverage, the next test data needs to be generated, and the next test data and the corresponding next expected display state are added to the candidate test set to obtain a new candidate test set. This process is repeated until the display state coverage of the new candidate test set is greater than the preset coverage, at which point the target test set is generated. In this way, the display state coverage of the candidate test set can be automatically improved, and the final display state coverage of the target test set can reach the preset coverage, enabling the target test set to comprehensively test the page under test, thereby improving the efficiency and accuracy of the test.

[0105] In this embodiment, test data corresponding to the sample data is generated. The expected display state corresponding to the test data is determined based on the first page code and the test data. A candidate test set is then generated based on the test data and the expected display state, and a target test set is determined based on the candidate test set. In this way, similar test data is generated using the sample data to simulate user input, reducing the development cost of manually generating test data. Determining the expected display state corresponding to the test data using the first page code and the test data, and adding it to the target test set, provides a standard reference for testing the page under test using the target test set, thereby ensuring the accuracy of the test.

[0106] See also Figure 3A In step 103, the updated page code obtained by updating the page to be tested is obtained, and the display status of each update of the page to be tested is determined based on the updated page code and at least two test data.

[0107] In practical applications, test pages are frequently modified and optimized based on changes in business needs, user feedback, or design iterations. These modifications may include, but are not limited to, adding new functional modules, adjusting page layout, improving user interaction, and enhancing visual effects. For example, the development team might decide to add a new tab to the test page to provide more information or navigation, or modify the existing layout to make it more intuitive and easier to use. In this case, to ensure the update of the test page is implemented correctly, the page code needs to be modified accordingly. The modified page code is the updated page code, and the display state output by the test page when running the updated page code is the updated display state. However, in practice, any changes to the existing code may have a chain reaction on other functions of the page; that is, when the code of the test page is updated, other functions of the test page may be affected. For example, developers might want to add a tab before the product title on the test page. To achieve this effect, they add new code to the original code, resulting in the updated page code. When the updated page code was actually run on the test page, it was found that the product titles on the test page could not be displayed, meaning that the added code affected the logic of the original code. Therefore, to avoid this situation, the updated page code needs to be tested using a target test set before actual application. The updated display state should simulate the actual effect of the updated page code. Specifically, for each test case, the test data is used as input to the updated page code, and the updated display state of the test page is obtained by executing the updated page code.

[0108] In step 104, the test results of the updated page code are determined based on each updated display state and each expected display state.

[0109] Here, using the expected display state as the standard, the difference between the updated display state and the original expected display state can be accurately evaluated, thereby determining the test results of the updated page code. The test results include "pass" and "fail." A pass indicates that the updated page code does not affect the original code logic and can be used directly; a fail indicates that the updated page code affects the original code logic and requires modification and adjustment.

[0110] In some embodiments, step 104 can be implemented through the following process:

[0111] Each updated display state is compared with its corresponding expected display state. If every updated display state matches its expected state, the updated page code has not affected the original code logic, and the test result is considered passed. If any updated display state differs from its expected state, it also indicates that the updated page code has not affected the original code logic. In this case, the comparison result between the updated and expected display states needs to be determined first, and then the test result is further determined based on the comparison result. The comparison result is determined based on the areas of difference between the updated and expected display states, and the differences between the updated and expected display states can be clearly seen through the comparison results.

[0112] In some embodiments, determining the test result based on the comparison result includes the following process: determining a first region from the updated display state and determining a second region from the expected display state. The first and second regions are regions where there is a difference between the updated display state and the corresponding expected display state. For example, in a certain updated display state, the title of product A is "apple" and the title of product B is "orange"; in the expected display state corresponding to this updated display state, the title of product A is "apple" and the title of product B is blank. Therefore, the region containing the title of product B in this updated display state is determined as the first region, and the region containing the label of product B in the corresponding expected display state is determined as the second region. Then, the first and second regions are determined as the comparison result; that is, the comparison result includes both the first and second regions. Afterwards, the comparison result can be output and displayed on the device's display interface. Users manually judge whether the difference between the two different regions in the comparison result is reasonable. If it is determined to be reasonable, the user will input the expected input information; if it is determined to be unreasonable, the user will input the unexpected input information. For example, in the comparison results, the price of product A in the first area is 100, and the price of product A in the second area is 120. Since the purpose of updating the test page is to adjust the price of product A, the difference between the two areas in the comparison results is reasonable, and the updated display state meets expectations. Alternatively, correspondingly, if the comparison results determine that the updated display state meets expectations, the test result is determined to be passed; if the comparison results determine that the updated display state does not meet expectations, the test result is determined to be failed. In this way, determining whether the updated display state meets expectations through comparison results allows for a more accurate assessment of whether the updated page code has affected historical logic, thereby improving the accuracy of data processing.

[0113] In this embodiment, if each updated display state is identical to its corresponding expected display state, the test result is directly determined as passed. If any updated display state differs from its corresponding expected display state, the comparison result between the updated and expected display states is first determined, and then the test result is determined by manually judging the differences in the comparison result. This not only improves the efficiency of generating test results but also enhances the accuracy of test results by combining manual comparison.

[0114] In some embodiments, when the test result is a failure, the updated page code is updated to obtain new updated page code. Then, based on the new updated page code and the target test set, steps 103 and 104 are repeated to determine the test result of the new updated page code. When the new updated page code passes the test, the code of the page to be tested is updated with the new updated page code. If the test result of the new updated page code is still a failure, the code can continue to be modified until a test result of passing is obtained. This ensures the quality of the updated page code, ensures that the modifications to the page to be tested are reasonable, reduces the occurrence of online problems, and thus improves the stability of the page to be tested.

[0115] In this embodiment, sample data of the page to be tested is obtained, and a target test set for the page to be tested is generated based on the sample data. The target test set includes at least two test data and the expected display state corresponding to each test data. The at least two test data can test every display state of the page to be tested. This automatic generation of the target test set using sample data improves the efficiency and accuracy of target test set generation, thereby improving the efficiency and accuracy of testing the page to be tested using the target test set. When the code of the page to be tested is updated, each updated display state of the page to be tested is determined using the updated page code and at least two test data. Each updated display state is compared with each expected display state to determine whether the updated page code affects other code logic of the page to be tested. This improves the efficiency and accuracy of detecting updated page code, avoids online problems caused by code anomalies, and enhances the security and stability of the page to be tested.

[0116] The data processing method provided in this application can be applied to various application scenarios such as social media platforms, e-commerce platforms, and news website platforms. Automatically generating target test sets can save time and cost in writing test cases, improve testing efficiency, and reduce error rates. When testing the page to be tested using the target test set, it can comprehensively ensure that the page's display state meets design expectations, improving user experience and satisfaction.

[0117] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0118] Taking an e-commerce scenario as an example, the test page displays multiple products, each with various styles: flash sale items, regular promotional items, crowdfunding items, special promotional items, member items, etc. Each product displays a different style, but their overall layout is largely consistent. If a new tag needs to be added before the product title, it's necessary to test and enumerate all display states of the test page to determine if the state of each product has any impact.

[0119] In related technologies, enumerating all display states of a page under test requires manually writing unit test data, inputting the test data into the unit, running the unit's code, and then determining whether the output matches the expected output. If they match, the test passes; otherwise, there's a problem with the code, requiring manual correction. Therefore, during testing, testers not only need to be familiar with each business function of the unit but also need to manually write a large number of test cases.

[0120] This application's embodiments generate a target test set using a random method, and the display state coverage of the target test set reaches a preset coverage rate, thus enabling the enumeration of all display states of the page to be tested. If it's necessary to update the code to add a tag before the product title, the updated page code can be directly obtained, and testing can be performed using the updated page code and the target test set. This allows for simple and quick testing, ensuring code quality. When the code of the page to be tested is updated, the updated page code can be used to run test data from the target test set to determine if the updated display state is consistent with the expected display state in the target test set. If they are consistent, the logic of the updated page code has not affected the original code; if they are inconsistent, it can be quickly determined that the updated page code has affected the logic of the original code. In this case, manual comparison of all page state changes can be used to determine if the impact is reasonable, thereby avoiding issues where code updates cause anomalies on the page to be tested.

[0121] See Figure 4 , Figure 4 This is a flowchart illustrating the page code testing process provided in this application embodiment. The electronic device implementing this process can be the aforementioned terminal or server. The following will be combined with... Figure 4 The steps shown are explained in detail.

[0122] In step 401, the updated page code is obtained.

[0123] Here, we obtain the updated page code after updating the page to be tested.

[0124] In step 402, each test data is acquired.

[0125] Here, each test data is obtained through the target test set, which includes at least two test data and the expected display state corresponding to each test data.

[0126] In step 403, the display status after each update is determined.

[0127] Here, the updated page code and each test data are used to determine the display status of the page to be tested after each update.

[0128] In step 404, it is determined whether the displayed state after each update is consistent with the corresponding expected displayed state.

[0129] Here, each updated display state has a corresponding expected display state. When each updated display state is the same as its corresponding expected display state, step 406 is executed; when any updated display state is different from its corresponding expected display state, step 405 is executed.

[0130] In step 405, it is determined whether the updated display status meets expectations.

[0131] Here, based on the areas where there is a difference between the updated display state and the expected display state, it is manually determined whether it meets the expectations. If it meets the expectations, step 406 is executed; if it does not meet the expectations, step 407 is executed.

[0132] In step 406, the test passed.

[0133] Here, the test result for the updated page code is confirmed as "test passed".

[0134] In step 407, the test failed, and the updated page code was updated.

[0135] Here, if there is a difference between the updated and expected display states, and the updated state does not meet expectations, the test result for the updated page code is determined to be a failure. The updated page code is then modified to implement the update, and step 401 is executed again after the update.

[0136] See Figure 5 , Figure 5 This is another flowchart illustrating the generation of a target test set provided in this application embodiment. The electronic device implementing this process can be the aforementioned terminal or server. The following will be combined with... Figure 5 Detailed instructions for the steps shown:

[0137] In step 501, test data is automatically generated.

[0138] Here, the test data is generated using a random method. A sample of user-input data is analyzed to generate random data, which is then used as the test data.

[0139] In step 502, the expected display state is determined.

[0140] Here, the test data is used as input to the code on the first page, the code on the first page is executed, and the output result is used as the expected display state.

[0141] In step 503, a candidate test set is generated.

[0142] Here, if this is the first time test data and expected display state are generated, then the test data and expected display state are directly determined as the candidate test set. If this is not the first time test data and expected display state are generated, then the test data and expected display state generated this time, along with all previously generated test data and expected display states, are determined together as the candidate test set.

[0143] In step 504, it is determined whether the display status coverage has increased.

[0144] Here, if the display status coverage does not increase, step 501 is executed again; if the display status coverage increases, step 505 is executed.

[0145] In step 505, it is determined whether the display status coverage is greater than the preset coverage.

[0146] Here, if the display status coverage is not greater than the preset coverage, then step 501 is executed again; if the display status coverage is greater than the preset coverage, then step 506 is executed.

[0147] In step 506, the target test set is generated.

[0148] Here, the candidate test set is determined as the target test set.

[0149] See Figure 6 , Figure 6 This is another schematic diagram of the process for generating test data provided in the embodiments of this application. The electronic device that implements this process can be the aforementioned terminal or server. The following will be combined with Figure 6 Detailed instructions for the steps shown:

[0150] In step 601, sample data is obtained.

[0151] Here, sample data refers to the front-end data input by the user, which is divided into basic data and complex data. Complex data is further divided into object type and array type, and can contain multiple basic data or complex data.

[0152] In step 602, it is determined whether the sample data is basic data.

[0153] Here, if the sample data is the basic data, proceed to step 605; if the sample data is not the basic data, proceed to step 603.

[0154] In step 603, the sample data is processed recursively.

[0155] Here, recursive call processing refers to the process of extracting multiple first sub-data from the sample data, and then extracting multiple second sub-data from each sub-data. The get_Random function can be used to extract the sample data and sub-data.

[0156] In step 604, it is determined whether to recursively return to the basic data.

[0157] Here, each time the sample data is recursively processed, it is determined whether each piece of data obtained through recursion is basic data. If it is basic data, it means that the recursion has reached the basic data and step 605 is executed; if it is not basic data, it means that the recursion has not reached the basic data and step 603 is still required.

[0158] In step 605, basic data is generated.

[0159] Here, basic data is generated directly using a random basic data type generator. The process is as follows:

[0160] 1. Determine if the data type is string; if yes, generate a random string and return it; if no, proceed to the next step 2.

[0161] 2. Determine if the data type is a number; if yes, generate a random number and return it; if no, proceed to the next step 3.

[0162] 3. Determine if the data type is a Boolean value; if yes, generate a random Boolean value and return it; if no, proceed to the next step 4.

[0163] 4. Return data. This is because other data only contains null and undefined, so there is no need to generate it randomly.

[0164] In this way, when the sample data is basic data, the basic data can be directly generated using a random basic data type generator, which can efficiently simulate user input. When the sample data is complex data, the complex data is continuously called recursively. When the recursion reaches the basic data, the basic data is generated using a random basic data type generator. Then, the multiple generated basic data are combined according to the data structure of the sample data, which can also simulate user input.

[0165] This application embodiment achieves automatic generation of the target test set and automatic improvement of its coverage, thereby reducing development costs and manual comparison steps. The target test set in this application embodiment can enumerate all display states of the page to be tested, enabling comprehensive testing of the updated page code, avoiding online issues caused by code anomalies, and improving the security and stability of the page to be tested. Furthermore, the target test set of this application can be applied to other page code, increasing the coverage of that code and ensuring code quality.

[0166] The following description continues to illustrate the exemplary structure of the data processing apparatus 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2B As shown, the software modules stored in the data processing device 455 of the memory 450 may include:

[0167] The acquisition module 4551 is used to acquire sample data of the page to be tested, and the sample data is used to test any display state of the page to be tested.

[0168] The generation module 4552 is used to generate a target test set for the page to be tested based on the sample data. The target test set includes at least two test data and an expected display state corresponding to each test data. The at least two test data are used to test each display state of the page to be tested.

[0169] The acquisition module 4551 is further configured to acquire the updated page code obtained by updating the page to be tested, and determine the display status of each update of the page to be tested based on the updated page code and the at least two test data.

[0170] The determination module 4553 is used to determine the test result of the updated page code based on each of the updated display states and each of the expected display states.

[0171] In some embodiments, the generation module 4552 is further configured to generate test data corresponding to the sample data, obtain the first page code of the page to be tested in the expected display state; determine the expected display state corresponding to the test data based on the first page code and the test data; generate a candidate test set based on the test data and the expected display state; and determine a target test set based on the candidate test set.

[0172] In some embodiments, the determining module 4553 is further configured to: determine the display state coverage of the candidate test set for the page to be tested; when the display state coverage is less than or equal to a preset coverage, generate next test data corresponding to the sample data based on the sample data; determine the next expected display state corresponding to the next test data based on the first page code and the next test data; add the next test data and the next expected display state to the candidate test set to obtain a new candidate test set; and determine the target test set based on the new candidate test set.

[0173] In some embodiments, the determining module 4553 is further configured to determine the candidate test set as the target test set when the display state coverage is greater than the preset coverage.

[0174] In some embodiments, the generation module 4552 is further configured to determine a first data type of the sample data; when the first data type belongs to a first preset type, generate the test data based on the first data type; when the first data type belongs to a second preset type, determine a plurality of first subtypes included in the first data type, and generate the test data based on the plurality of first subtypes.

[0175] In some embodiments, the generation module 4552 is further configured to, for each of the first subtypes, generate first candidate data based on the first subtype when the first subtype belongs to a first preset type; determine a plurality of second subtypes included in the first subtype when the first subtype belongs to a second preset type, until each of the second subtypes is the first preset type, generate second candidate data based on each of the second subtypes; and determine the test data based on the first candidate data and the second candidate data.

[0176] In some embodiments, the determining module 4553 is further configured to, for each piece of test data, use the test data as input data for the updated page code, execute the updated page code, and obtain each updated display state of the page to be tested.

[0177] In some embodiments, the determining module 4553 is further configured to determine the test result as passed when each of the updated display states is the same as its corresponding expected display state; and to determine the comparison result between the updated display state and the expected display state when any of the updated display states is different from the corresponding expected display state, and to determine the test result based on the comparison result.

[0178] In some embodiments, the determining module 4553 is further configured to determine a first region from the updated display state and a second region from the expected display state, wherein the first region and the second region are regions where there is a difference between the updated display state and the corresponding expected display state; and to determine the first region and the second region as the comparison result.

[0179] In some embodiments, the determining module 4553 is further configured to determine the test result as a test pass when the updated display state is determined to meet expectations based on the comparison result; and to determine the test result as a test fail when the updated display state is determined to not meet expectations based on the comparison result.

[0180] In some embodiments, the determining module 4553 is further configured to update the updated page code when the test result is that the test fails, to obtain a new updated page code; and to determine the test result of the new updated page code based on the new updated page code and the target test set.

[0181] In this embodiment, a data processing apparatus is provided, capable of acquiring sample data of a page to be tested, generating a target test set for the page based on the sample data, wherein the target test set includes at least two test data and an expected display state corresponding to each test data, and the at least two test data can test each display state of the page to be tested. This automatic generation of the target test set from sample data significantly improves the efficiency and accuracy of target test set generation, thereby improving the efficiency and accuracy of testing the page to be tested using the target test set. When the code of the page to be tested is updated, each updated display state of the page to be tested is determined using the updated page code and at least two test data, and each updated display state is compared with each expected display state to determine whether the updated page code affects other code logic of the page to be tested, improving the efficiency and accuracy of detecting updated page code, avoiding online problems caused by code anomalies, and improving the security and stability of the page to be tested.

[0182] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the data processing method described in this application.

[0183] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the data processing method provided in this application. For example, ... Figure 3A The data processing method is shown.

[0184] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0185] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0186] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored in a portion of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0187] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0188] In summary, this application's embodiments achieve automatic generation of the target test set and automatic improvement of its coverage, thereby reducing development costs and manual comparison steps. The target test set in this application's embodiments can enumerate all display states of the page to be tested, enabling comprehensive testing of the updated page code, preventing online issues caused by code anomalies, and improving the security and stability of the page to be tested. Furthermore, the target test set of this application can be applied to other page code, increasing the coverage of that code and ensuring code quality.

[0189] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The method includes: Obtain sample data of the page to be tested, the sample data being used to test any display state of the page to be tested; Based on the sample data, a target test set is generated for the page to be tested. The target test set includes at least two test data and the expected display state corresponding to each test data. The at least two test data are used to test each display state of the page to be tested. Obtain the updated page code obtained by updating the page to be tested, and determine the display state of the page to be tested for each update based on the updated page code and the at least two test data. The test results of the updated page code are determined based on each of the updated display states and each of the expected display states.

2. The method according to claim 1, characterized in that, The process of generating the target test set for the page to be tested based on the sample data includes: Generate test data corresponding to the sample data; Obtain the first page code of the page to be tested in the expected display state, and determine the expected display state corresponding to the test data based on the first page code and the test data; Based on the test data and the expected display state, a candidate test set is generated; The target test set is determined based on the candidate test set.

3. The method according to claim 2, characterized in that, The step of determining the target test set based on the candidate test set includes: Determine the coverage of the display state of the candidate test set for the page to be tested; When the display status coverage is less than or equal to a preset coverage, the next test data corresponding to the sample data is generated based on the sample data. Based on the first page code and the next test data, determine the next expected display state corresponding to the next test data; The next test data and the next expected display state are added to the candidate test set to obtain a new candidate test set; The target test set is determined based on the new candidate test set.

4. The method according to claim 3, characterized in that, The method further includes: When the display state coverage is greater than the preset coverage, the candidate test set is determined as the target test set.

5. The method according to claim 2, characterized in that, The generation of test data corresponding to the sample data includes: Determine the first data type of the sample data; When the first data type belongs to the first preset type, the test data is generated based on the first data type; When the first data type belongs to the second preset type, determine the multiple first subtypes included in the first data type, and generate the test data based on the multiple first subtypes.

6. The method according to claim 5, characterized in that, The generation of the test data based on the plurality of first subtypes includes: For each of the first subtypes, when the first subtype belongs to a first preset type, first candidate data is generated based on the first subtype; When the first subtype belongs to the second preset type, determine the multiple second subtypes included in the first subtype until each second subtype is the first preset type, and generate second candidate data based on each second subtype; The test data is determined based on the first candidate data and the second candidate data.

7. The method according to any one of claims 1 to 6, characterized in that, The step of determining the display status of the page to be tested after each update based on the updated page code and the at least two test data includes: For each set of test data, the test data is used as input data for the updated page code. The updated page code is then executed to obtain the updated display state of the page to be tested.

8. The method according to any one of claims 1 to 6, characterized in that, The step of determining the test result of the updated page code based on each updated display state and each expected display state includes: If the updated display state is the same as the corresponding expected display state, the test result is determined to be a pass. If any of the updated display states differs from the corresponding expected display states, a comparison result between the updated display states and the expected display states is determined, and the test result is determined based on the comparison result.

9. The method according to claim 8, characterized in that, Determining the comparison result between the updated display state and the expected display state includes: A first region is determined from the updated display state, and a second region is determined from the expected display state, wherein the first region and the second region are regions where there is a difference between the updated display state and the corresponding expected display state; The first region and the second region are determined as the comparison result.

10. The method according to claim 8, characterized in that, Determining the test result based on the comparison results includes: When it is determined, based on the comparison results, that the updated display status meets expectations, the test result is determined to be a pass. When it is determined, based on the comparison results, that the updated display status does not meet expectations, the test result is determined to be a test failure.

11. The method according to claim 10, characterized in that, The method further includes: When the test result is that the test fails, the updated page code is updated to obtain a new updated page code; Based on the new updated page code and the target test set, the test results of the new updated page code are determined.

12. A data processing apparatus, characterized in that, The device includes: The acquisition module is used to acquire sample data of the page to be tested, and the sample data is used to test any display state of the page to be tested. A generation module is used to generate a target test set for the page to be tested based on the sample data. The target test set includes at least two test data and an expected display state corresponding to each test data. The at least two test data are used to test each display state of the page to be tested. The acquisition module is further configured to acquire the updated page code obtained by updating the page to be tested, and determine the display status of each update of the page to be tested based on the updated page code and the at least two test data. A determination module is used to determine the test result of the updated page code based on each of the updated display states and each of the expected display states.

13. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 11.

14. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method described in any one of claims 1 to 11.

15. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method according to any one of claims 1 to 11.

Images