A user page testing method and device and related products

Abstract

The application discloses a user page testing method and device and related products, and the method comprises the following steps: obtaining target page information of a target user page in a target project, wherein the target page information comprises target metadata randomly generated based on historical interface data of multiple interfaces of target code of the target user page; then writing the target metadata into a global variable window of the target code, wherein the global variable window comprises variables corresponding to the multiple interfaces respectively; running the target code to obtain code coverage information representing a probability of successfully executed code in multiple lines of code; after the running of the target code is completed, if the code coverage information indicates that the probability of the successfully executed code increases, performing screenshot on a page after the running of the target code is completed to obtain a screenshot result; and finally generating a target test case according to the target metadata, the code coverage information and the screenshot result, wherein the target test case is used for testing the target user page. In this way, the testing efficiency and the testing accuracy are improved.

Description

Technical Field

[0001] This application relates to the field of page testing technology, and in particular to a user page testing method, apparatus and related products. Background Technology

[0002] To ensure that the user interface (UI) is displayed correctly and that user interaction is normal and smooth, the user interface needs to be tested.

[0003] In related technologies, user pages are typically tested manually, or testers write test cases based on functions (or components). Manual testing is inefficient and prone to errors; manually writing test cases is time-consuming, further contributing to low efficiency and the likelihood of errors in manually written test cases. Summary of the Invention

[0004] This application provides a user page testing method, apparatus, and related products, aiming to improve testing efficiency and accuracy.

[0005] The first aspect of this application provides a user page testing method, including:

[0006] Obtain the target page information of the target user page; the target user page is any user page in the target project; the target page information includes target metadata, which is randomly generated based on historical interface data of multiple interfaces of the target code; the target code is the code of the target user page, which includes multiple lines of code.

[0007] Write the target metadata into the global variable window of the target code; the global variable window includes variables corresponding to multiple interfaces, and each variable corresponds one-to-one with multiple data in the target metadata;

[0008] Run the target code to obtain code coverage information; code coverage information represents the probability of successfully executing code among multiple lines of code;

[0009] After the target code finishes running, if the code coverage information indicates an increased probability of successfully executed code, then take a screenshot of the page after the target code finishes running and obtain the screenshot result.

[0010] Based on the target metadata, code coverage information, and screenshot results, target test cases are generated; these test cases are used to test the target user page.

[0011] A second aspect of this application provides a user page testing apparatus, comprising:

[0012] The acquisition module is used to acquire the target page information of the target user page; the target user page is any user page in the target project; the target page information includes target metadata, which is randomly generated based on historical interface data of multiple interfaces of the target code; the target code is the code of the target user page, which includes multiple lines of code.

[0013] The writing module is used to write target metadata into the global variable window of the target code; the global variable window includes variables corresponding to multiple interfaces, and these variables correspond one-to-one with multiple data in the target metadata;

[0014] The execution module is used to run the target code and obtain code coverage information; code coverage information represents the probability of successfully executing code among multiple lines of code;

[0015] The screenshot module is used to take a screenshot of the page after the target code has finished running, if the code coverage information indicates that the probability of the code that was executed successfully has increased, and obtain the screenshot result.

[0016] The test case generation module is used to generate target test cases based on target metadata, code coverage information, and screenshot results; the target test cases are used to test the target user page.

[0017] A third aspect of this application provides a device comprising a processor and a memory:

[0018] The memory is used to store program code and transmit the program code to the processor;

[0019] The processor is used to execute the steps of the user page testing method provided in the first aspect according to the instructions in the program code.

[0020] A fourth aspect of this application provides a computer-readable storage medium for storing program code for performing the steps of the user page testing method provided in the first aspect.

[0021] The fifth aspect of this application provides a computer program product, including a computer program or instructions that, when executed, implement the steps of the user page testing method provided in the first aspect.

[0022] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0023] In this application's technical solution, target page information of the target user page in the target project is obtained. This target page information includes target metadata randomly generated from historical interface data of multiple interfaces based on the target code of the target user page. Then, the target metadata is written into a global variable window of the target code, which includes variables corresponding to multiple interfaces, with each variable corresponding to a specific piece of data in the target metadata. Further, the target code is run to obtain code coverage information representing the probability of successful execution of code in multiple lines of code. After the target code runs, if the code coverage information indicates an increased probability of successful execution, a screenshot of the page after the target code runs is taken, and the screenshot result is obtained. Finally, based on the target metadata, code coverage information, and screenshot result, target test cases are generated, which are used to test the target user page.

[0024] In this way, target metadata is randomly generated based on historical data from multiple interfaces of the target code, eliminating the need for testers to construct test data themselves. By writing the target metadata into the global variable window of the target code, code containing the target metadata can be executed when the target code is run. If the probability of successful execution of the code increases, it indicates that the number of lines of code executed successfully in the current target code has increased compared to historical code. Target test cases can then be generated based on the target metadata, code coverage information, and screenshot results, and testing can be performed using these target test cases. This achieves automated test case generation without the need for manual coding, improving testing efficiency. Furthermore, no coding is required; only the target metadata is randomly generated based on historical interface data, which can then be combined with the target code to generate test cases, avoiding errors from manual testing or coding and improving testing accuracy. Attached Figure Description

[0025] Figure 1 A schematic diagram illustrating a user page testing method provided in an embodiment of this application;

[0026] Figure 2 A flowchart illustrating a user page testing method provided in an embodiment of this application;

[0027] Figure 3a A schematic diagram of a user page test provided in an embodiment of this application;

[0028] Figure 3b A schematic diagram of a page containing project information provided in an embodiment of this application;

[0029] Figure 3c A schematic diagram of a page containing page information is provided as an embodiment of this application;

[0030] Figure 4a A schematic diagram of a code page provided for an embodiment of this application;

[0031] Figure 4b A schematic diagram of a settings page provided in an embodiment of this application;

[0032] Figure 4c A page illustration of another code provided for an embodiment of this application;

[0033] Figure 5 A schematic diagram of an abnormal test case viewing page provided in an embodiment of this application;

[0034] Figure 6 A flowchart illustrating a user page testing process provided in an embodiment of this application;

[0035] Figure 7 A flowchart illustrating another user page testing process provided in this application embodiment;

[0036] Figure 8 This is a schematic diagram of the structure of a user page testing device provided in an embodiment of this application;

[0037] Figure 9 This is a schematic diagram of the server structure in an embodiment of this application;

[0038] Figure 10 This is a schematic diagram of the structure of a terminal device in an embodiment of this application. Detailed Implementation

[0039] Front-end testing refers to testing multiple user pages of a front-end application. The main purposes of front-end testing are twofold: firstly, to ensure that the user interface (UI) displays correctly as expected; and secondly, to ensure that the interaction between the user page and the user is normal, meaning that the user can operate the user page smoothly.

[0040] In related technologies, there are two methods for front-end testing. One is manual testing, where testers maintain a set of test cases describing the current system (or application), and then manually access and observe the system's user pages according to the test cases. However, manual testing is inefficient and prone to errors.

[0041] Another approach involves testers writing test cases based on functions (or components), manually constructing all possible input data for the function and determining its correct output. This can be done using front-end unit testing frameworks such as Jest and Mocha. However, this method results in a longer test case writing cycle, greater maintenance difficulties, and a focus on testing code logic with less attention to user page testing, leading to lower testing efficiency and accuracy.

[0042] In view of the above problems, this application provides a user page testing method, apparatus, and related products. The technical solution provided in this application involves obtaining target page information of the target user page in the target project. This target page information includes target metadata randomly generated from historical interface data of multiple interfaces based on the target code of the target user page. Then, the target metadata is written into a global variable window of the target code, which includes variables corresponding to multiple interfaces, with each variable corresponding one-to-one with multiple data points in the target metadata. Further, the target code is run to obtain code coverage information representing the probability of successful execution of code in multiple lines of code. After the target code execution is complete, if the code coverage information indicates an increased probability of successful execution, a screenshot of the page after the target code execution is completed is taken, and a screenshot result is obtained. Finally, based on the target metadata, code coverage information, and screenshot result, target test cases are generated, which are used to test the target user page.

[0043] In this way, target metadata is randomly generated based on historical data from multiple interfaces of the target code, eliminating the need for testers to construct test data themselves. By writing the target metadata into the global variable window of the target code, code containing the target metadata can be executed when the target code is run. If the probability of successful execution of the code increases, it indicates that the number of lines of code executed successfully in the current target code has increased compared to historical code. Target test cases can then be generated based on the target metadata, code coverage information, and screenshot results, and testing can be performed using these target test cases. This achieves automated test case generation without the need for manual coding, improving testing efficiency. Furthermore, no coding is required; only the target metadata is randomly generated based on historical interface data, which can then be combined with the target code to generate test cases, avoiding errors from manual testing or coding and improving testing accuracy.

[0044] By acquiring target page information for the target user page in the target project, including target metadata randomly generated from historical interface data of multiple interfaces based on the target code of the target user page; then, writing the target metadata into a global variable window of the target code, which includes variables corresponding to each of the multiple interfaces, with each variable corresponding one-to-one with the data in the target metadata; further, running the target code to obtain code coverage information representing the probability of successful execution of code in multiple lines of code; after the target code finishes running, if the code coverage information indicates an increased probability of successful execution, taking a screenshot of the page after the target code finishes running; finally, based on the target metadata, code coverage information, and screenshot results, generating target test cases, which are used to test the target user page.

[0045] In this way, target metadata is randomly generated based on historical data from multiple interfaces of the target code, eliminating the need for testers to construct test data themselves. By writing the target metadata into the global variable window of the target code, code containing the target metadata can be executed when the target code is run. If the probability of successful execution of the code increases, it indicates that the number of lines of code executed successfully in the current target code has increased compared to historical code. Target test cases can then be generated based on the target metadata, code coverage information, and screenshot results, and testing can be performed using these target test cases. This achieves automated test case generation without the need for manual coding, improving testing efficiency. Furthermore, no coding is required; only the target metadata is randomly generated based on historical interface data, which can then be combined with the target code to generate test cases, avoiding errors from manual testing or coding and improving testing accuracy.

[0046] Figure 1 An exemplary scenario architecture diagram of a user page testing method is shown. Figure 1 Includes server 10. Figure 1 The server 10 shown can be a standalone physical server, a server cluster consisting of multiple physical servers, or a distributed system. Additionally, the server can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0047] Server 10 obtains the target page information of the target user page. The target user page is any user page within the target project; the target page information includes target metadata, which is randomly generated based on historical interface data from multiple interfaces of the target code; the target code is the code of the target user page, and the target code includes multiple lines of code.

[0048] As an example, suppose the target project includes 10 user pages, and the target user page is any one of the 10 user pages. The target page information may include target metadata A. Target metadata A is randomly generated based on the historical interface data corresponding to multiple interfaces of the target code. For example, if the historical interface data is 1 and ABC, then the target metadata can be 3 and DEF.

[0049] It should be understood that there is a correspondence between the target code in the backend and the user page in the frontend, and multiple interfaces correspond to multiple inputs on the user page. For example, the user page displays "Name: xx", where "xx" represents the content that needs to be filled in. This "Name: xx" can correspond to an interface in the target code. During the testing of the user page, it is necessary to construct the "input" data. In related technologies, this is generally done manually, which leads to low testing efficiency and a large workload. The embodiments of this application randomly generate target metadata based on historical data from multiple interfaces in the target code, eliminating the need for testers to construct test data themselves, thereby improving testing efficiency and reducing workload.

[0050] Server 10 writes the target metadata into the global variable window of the target code. The global variable window includes variables corresponding to multiple interfaces, and these variables correspond one-to-one with multiple data points in the target metadata.

[0051] It should be understood that the global variable window can include all variables in the target code. The target metadata is randomly generated based on the historical interface data (i.e., historical variables) of multiple interfaces in the target code. Therefore, there is a correspondence between each variable in the global variable window and each data in the target metadata. By writing the target metadata into the global variable window, that is, replacing the historical interface data of multiple interfaces in the target code with the target metadata, test cases can be generated.

[0052] Server 10 runs the target code and obtains code coverage information. Code coverage information represents the probability of successfully executing code within a given set of lines.

[0053] It should be understood that if the target metadata is written to the global variable window, each line of code should be able to execute successfully when the target code is run. Successful execution indicates that the target metadata meets the data conditions or data range of the interface, while execution failure indicates that the target metadata does not meet the data conditions or data range of the interface. Therefore, it is necessary to obtain code coverage information to determine whether the test cases generated based on the target metadata can be saved.

[0054] After the target code finishes running, if the code coverage information indicates an increased probability of successfully executed code, server 10 will take a screenshot of the page after the target code finishes running and obtain the screenshot result.

[0055] It should be understood that if the probability of successfully executing code increases compared to the probability of successfully executing code in the past, it indicates that the number of lines of code successfully executed in the current target code has increased compared to the past code. In this case, the target metadata can generate a test case for testing.

[0056] Server 10 generates target test cases based on target metadata, code coverage information, and screenshot results. These target test cases are used to test the target user page.

[0057] It should be understood that, in order to facilitate testing of the target user page, the target test cases need to be generated based on the target metadata, code coverage information, and screenshot results. The target metadata is used as the input for testing, the code coverage information is used as the basic information for the next target test case, and the screenshot results are used to represent the visual display results of the user page test, which is convenient for comparison with the test results.

[0058] This application embodiment randomly generates target metadata based on historical data from multiple interfaces of the target code, eliminating the need for testers to construct test data manually. By writing the target metadata into the global variable window of the target code, code containing the target metadata can be executed when the target code is run. If the probability of successful execution of the code increases, it indicates that the number of lines of code successfully executed by the current target code has increased compared to historical code. Target test cases can then be generated based on the target metadata, code coverage information, and screenshot results, and testing can be performed using these target test cases. This achieves automated test case generation without the need for manual coding, improving testing efficiency. Furthermore, no coding is required; only the target metadata is randomly generated based on historical interface data, which can then be combined with the target code to generate test cases, avoiding errors from manual testing or coding and improving testing accuracy.

[0059] In practice, the collection and processing of data in this application should strictly comply with the requirements of relevant regional laws and regulations, obtain the informed consent or separate consent of the subject of personal information, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0060] Figure 2 This is a flowchart illustrating a user page testing method provided in an embodiment of this application. Figure 2 The user page testing methods shown include:

[0061] S201: Obtain the target page information for the target user's page.

[0062] A project refers to a set of tasks corresponding to an application, while an application refers to the front-end program used to interact with the user. A project may include multiple phases such as requirements analysis, design, coding, testing, deployment, and maintenance. Each phase performs different operations on the application. For example, in the requirements analysis phase, user needs can be analyzed to determine the functions that need to be added, deleted, or optimized for the application; in the coding phase, code can be written for the application's functions, resulting in the application's source code, which is then stored in the project. The target project refers to the set of tasks corresponding to the application to be tested.

[0063] It should be understood that a project can be defined based on the application's development process. The application is the final deliverable of the project, and the tasks of each phase of the project (such as requirements analysis, design, coding, testing, deployment, and maintenance) are built upon the application.

[0064] It should be understood that the data required for testing user pages is generally stored on a local system or platform for ease of maintenance. Therefore, before generating test cases, testers need to integrate the project into the system or platform to initialize the target project and its multiple user pages, such as... Figure 3a As shown, Figure 3a The page displays the systems or platforms that the project is connected to.

[0065] In one possible implementation, as shown in Table 1 below, the project information for each project may include the following fields:

[0066] Table 1: Fields Included in the Project

[0067] field name Field Description ID Unique Identifier projectCnName Chinese version of the project codeDir The project's source code directory should be marked to indicate which directories' code needs instrumentation. codeCoverage Instrumentation information for all code in the project (displayed as a JSON array).

[0068] ID represents a unique identifier for a project. IDs are generally used to retrieve page information for multiple user pages within a project.

[0069] projectCnName represents the Chinese name of the project, which is a simple description of the project. This allows testers to quickly locate the project that needs to be tested from among multiple projects.

[0070] codeDir represents the source code directory of the project. It can generally be a string separated by semicolons and is used for the valid code range in the target project, such as: api; data; components.

[0071] It should be understood that since a project may include code that does not need to be tested, such as external packages, configurations, and project builds, it is necessary to determine the scope of the code to be tested in order to filter out the code that does not need to be tested in order to improve testing efficiency.

[0072] codeCoverage refers to the instrumentation information saved after instrumenting the source code of a project. It is generally used to determine code coverage information later, which facilitates the generation of test cases or the adjustment of target metadata based on code coverage information.

[0073] It should be understood that after a project is integrated into a system or platform, it can be like... Figure 3b The page shown allows testers to maintain and modify project information.

[0074] The target user page can be any user page within the target project. In this embodiment, the generation and testing processes of test cases are illustrated using the target user page as an example. The generation and testing processes of test cases for other user pages within the target project are similar to those for the target user page, and therefore will not be repeated.

[0075] Since the test cases for user page testing in this embodiment are generated according to the page dimension, and each project contains several pages, it is necessary to maintain the page information. In one possible implementation, the page information for each user page in each project may include the fields shown in Table 2:

[0076] Table 2: Fields Included in User Page Information

[0077] field name Field Description ID Unique ID projectID Project ID pageCnName Chinese on the page href Page address includeInterface Page-related interfaces pageMetadataList Metadata entered on the page

[0078] ID represents a unique identifier for a page and is generally used to retrieve page information.

[0079] projectID represents the project ID of the project to which the user's page belongs.

[0080] pageCnName represents the Chinese name of the user page, which is a simple description of the user page. It is used to quickly locate the target user page from multiple user pages in the project.

[0081] href represents the test address of the user page, that is, the page address of the user page accessed when generating test cases.

[0082] includeInterface represents the domain name of the interface related to the user page. The backend interface is the main input of the frontend user page and can record interface data that affects the loading of the user page. This interface data is used to generate metadata.

[0083] `pageMetadataList` represents the metadata of user page inputs. Each user page has multiple page inputs, which refer to the content that needs to be entered on the user page. For example, if the user page displays "Name: xx", "xx" represents the page input. There is a one-to-one correspondence between multiple page inputs and multiple data in the target metadata.

[0084] It should be understood that after the project is integrated into the system or platform, the user page can be as follows: Figure 3c As shown on the page, testers can maintain and modify the page information on the user page.

[0085] It should be understood that a project may include multiple user pages, each with its own corresponding page information. This page information consists of key details about the user page, such as page ID, page address, page elements, and input variables (i.e., metadata), etc., without specific limitations here. The target user page can be any one of the multiple user pages, and the target page information is the page information corresponding to that target user page.

[0086] In this embodiment, the target page information may include at least target metadata. In one possible implementation, the target page information may also include a unique identifier for the target user page, the page address of the target user page, a unique identifier for the target project to which the target user page belongs, etc., without specific limitations.

[0087] Target metadata refers to the data used as page input for the target user page. Target metadata is randomly generated based on historical API data from multiple APIs of the target code. It should be understood that there is a one-to-one correspondence between the multiple page inputs of the front-end target user page and the multiple APIs of the back-end target code; therefore, the historical API data of these multiple APIs constitutes the historical page input of the target user page.

[0088] In one possible implementation, the target metadata can be generated in the following way:

[0089] A1: Retrieve historical interface data from multiple interfaces, as well as the field types of multiple interfaces.

[0090] Field type refers to the type of data stored in each field of the JSON array corresponding to the target user's page, such as number, string, Chinese characters, enumeration value, boolean value, time, HTTP, etc.

[0091] It should be understood that, since the target metadata is matched with each interface, the target metadata should conform to the field types of each interface when it is randomly generated in order to ensure the correctness and reliability of the data.

[0092] In order to generate richer target metadata, it is also possible to optimize by combining historical interface data to ensure that the values ​​of target metadata and historical interface data are different.

[0093] A2: Based on the historical interface data and field types of each interface, randomly generate the data corresponding to each interface.

[0094] Specifically, if the field type is numeric, a random number can be generated; if the field type is string, a random string can be generated; if the field type is Chinese, a random Chinese character can be generated; if the field type is boolean, a random true or false can be generated; if the field type is time, a random time can be generated; if the field type is http, a fixed value is generated; and if the field type is an enumeration value, a random enumeration value can be generated.

[0095] Furthermore, to generate richer target metadata, historical interface data can be combined. The randomly generated data is compared with the historical interface data; if they match, new data is randomly generated again; if they do not match, the old data is used as the target metadata. It should be noted that if the interface data for a certain interface is always a fixed value, no comparison is needed, and the fixed value is directly used as the target metadata.

[0096] A2: Use multiple data as target metadata.

[0097] It should be understood that in order to generate new test cases, the page input needs to be modified. In this embodiment of the application, multiple data in the target metadata are randomly generated based on the historical interface data of multiple interfaces. Compared with manually building test data, this improves testing efficiency, reduces workload, and is less prone to errors.

[0098] The target code is the code of the target user's page, and it consists of multiple lines of code. It should be noted that, in order to subsequently obtain code coverage information from the target code, in one possible implementation, the coverage calculation code can be written into the target code after it has been obtained.

[0099] The coverage calculation code is used to obtain code coverage information for the target code. Code coverage information represents the probability of successful execution of code within a set of lines.

[0100] It should be understood that during the test case preparation phase, some code needs to be pre-written to implement different functionalities. In this embodiment, instrumentation techniques can be used to obtain the result of whether a certain line of code was executed successfully.

[0101] As an example, target project information can be obtained based on the target project's unique identifier. Then, the target project code can be retrieved based on this information, and finally, instrumentation can be performed on the target project code according to its source code directory. This instrumentation of the target project code facilitates subsequent understanding of the execution status of the code corresponding to each user page.

[0102] Since project code is generally composed of three types: HTML, CSS, and JavaScript, inserting guard statements into these three types of code will allow you to obtain the execution status.

[0103] HTML (HyperText Markup Language) is a standard markup language used to create user-defined web pages. HTML defines the structure and content of a webpage. This is achieved through the use of tags (such as...). <h1>, , , Developers can place elements such as text, images, links, tables, and forms on user pages.

[0104] CSS (Cascading Style Sheets) is a style sheet language used to describe the rendering of HTML or XML documents (including various XML dialects such as SVG, MathML, or XHTML). CSS controls the appearance and layout of user pages, such as colors, fonts, spacing, borders, and backgrounds.

[0105] JavaScript is a lightweight, interpreted or just-in-time (JIT) compiled programming language characterized by its object-oriented, prototype-based, and weakly typed nature. JavaScript is used to implement dynamic functionalities on user pages, such as form validation, animation effects, interactive effects, and data requests.

[0106] A guard statement is a control structure used to evaluate conditions and perform corresponding actions. Guard statements contain code location information; when a guard statement is inserted, the code location information for that line of code is saved in the project information. Then, after the user page is rendered, the guard statement is executed, collecting the current code location and storing it as code coverage information in the test cases.

[0107] As an example, the code location information in a guard statement can be:

[0108] export interface Position{

[0109] filePath: string;

[0110] startLine:number;

[0111] startCol:number;

[0112] startOffset:number;

[0113] endLine:number;

[0114] endCol:number:endOffset:number;

[0115] }

[0116] In one possible implementation, since HTML, CSS, and JavaScript are different types, different methods are needed to calculate code coverage so that the obtained code coverage can be used as code coverage information.

[0117] As an example, when the code type is JavaScript, a globally executable function can be inserted as a guard statement before functions and conditional statements. For example:

[0118] function func(){

[0119] window._auto_test_coverage_count('filePath=index.js&startCol=9&startLine=7&startOffset=167&endCol=3&endLine=9&endOffset=209');

[0120] console.log('do some log');

[0121] }

[0122] Specifically, in the target code, the function `window.__auto_test_coverate_count` needs to be set to execute guard statements for code coverage statistics and reporting. For example:

[0123] window._auto_test_coverage_count = function(coverage) { / / Statistics and reporting of coverage console.log(coverage)

[0124] }

[0125] When the code type is HTML, attributes can be inserted into HTML tags to track which tags are rendered, allowing you to view the execution status of the HTML code. For example:

[0126] <div

[0127] data-auto-test="filePath=target / html / index.html&startCol=5&startLine=14&startOffset=292&endCol=19&endLine=14&amrendOffset=306">< / d iv>

[0128] Specifically, the target code needs to retrieve the attributes of HTML elements and report the probability of rendered elements (i.e., code coverage). For example:

[0129] const elements=document.querySelectorAll('[data-auto-test]');

[0130] elements.forEach(element=>{

[0131] const coverage=element.getAttribute('data-auto-test');

[0132] / / Statistics and reporting coverage

[0133] console.log(coverage)

[0134] });

[0135] When the code type is CSS, you can insert `content` within pseudo-elements of the CSS code, and then determine whether the CSS selector is effective by retrieving the `content` information from the pseudo-elements. For example:

[0136] .demo{

[0137] background-color:red;

[0138] }

[0139] .demo::before{content

[0140] 'filePath=target / css / index.css&startCol=1&startLine=1&startOffset0&endCo l=1&endLine=3&end0ffset=34'}

[0141] Specifically, the target code needs to obtain the pseudo-element content information of all elements and report the probability (i.e., code coverage) of the rendered CSS selectors. For example:

[0142] / / You can only get it after the page has finished loading.

[0143] window.addEventListener('load', () => {

[0144] const elements=document.querySelectorAll('*');

[0145] elements.forEach(element=>{

[0146] const pseudoElement=window.getComputedStyle(element'::before')

[0147] let pseudoElementContent =

[0148] pseudoElement.getPropertyValue('content');

[0149] if(pseudoElementContent===='none'){

[0150] return

[0151] }

[0152] / / Note: The retrieved content attribute value will contain quotation marks, for example, '"Hello, world!" needs to be removed.

[0153] const coverage = pseudoElementContent.slice(1, -1); / / Remove the leading and trailing quotes

[0154] / / Statistics and reporting coverage

[0155] console.log(coverage)

[0156] })

[0157] })

[0158] It should be understood that, in the embodiments of this application, by writing coverage calculation code into the target code, code coverage information can be obtained so as to serve as a condition for measuring test cases, without the need for manual investigation, thus improving testing efficiency.

[0159] S202: Write the target metadata to the global variable window of the target code.

[0160] Global variables are variables that can be accessed by any function or procedure in a program. The global variable window includes variables corresponding to multiple interfaces, and these variables correspond one-to-one with multiple data points in the target metadata. The global variable window is a window for managing global variables, such as adding, deleting, and modifying them, facilitating centralized management of global variables by testers.

[0161] S203: Run the target code to obtain code coverage information.

[0162] It should be understood that after the target metadata is written to the global variable window of the target code, the variables in the target code become the target metadata. Thus, by running the target code, it can be determined whether the code containing the target metadata has been executed successfully, thereby obtaining code coverage information.

[0163] In one possible implementation, when running the target code, the interface data of multiple interfaces of the target code can also be obtained as multiple target interface data; if new target interface data exists among the multiple target interface data, the new target interface data is converted into target metadata.

[0164] It should be understood that when the target user page is updated compared to the previous version, one or more new interfaces are added. At this time, the newly added interfaces do not have corresponding target metadata. Therefore, in order to enable the data configuration of the newly added interfaces, it is necessary to convert the target interface data of the newly added interfaces into target metadata so that the variables of the newly added interfaces can be overridden (or replaced) when the test cases are generated next time, thereby improving the comprehensiveness and reliability of the test.

[0165] S204: After the target code finishes running, if the code coverage information indicates an increased probability of successfully executed code, then take a screenshot of the page after the target code finishes running and obtain the screenshot result.

[0166] It should be understood that since the target metadata is randomly generated based on historical interface data from multiple interfaces, and the target metadata is configured through the target code, theoretically all code within the target code can be executed. However, because the target metadata is randomly generated, its randomness may cause the code corresponding to a certain interface to fail to execute. As an example, suppose the field type of interface A is numeric, the data range of interface A is 1 to 3, and the randomly generated target metadata is 4. Then, if 4 is input into interface A, interface A will either fail to execute or fail to execute.

[0167] Therefore, in this embodiment of the application, after the target code finishes running, it is necessary to obtain code coverage information, and then use the code coverage information to determine whether the probability of successfully executed code has increased compared with the probability of successfully executed code in the past, so as to determine whether target test cases can be generated based on target metadata.

[0168] It should be noted that, in order to avoid the situation where the successfully executed code is inconsistent but the success rate is increased, in this embodiment of the application, the increased probability of successfully executed code means that, compared with the probability of historically successfully executed code, there is successfully executed code among the historically failed code. As an example, the target code includes code 1 to code 10, and the historically successfully executed code is code 2 to code 6. Then, in the code coverage information, the successfully executed code, in addition to code 2 to code 6, also successfully executed code 1 and code 10. Thus, the code coverage information represents an increased probability of successfully executed code.

[0169] It should be understood that after the target code finishes running, a screenshot of the target user's page can be taken and used as a visual representation of the target test case, facilitating comparison with other test cases later.

[0170] S205: Generate target test cases based on target metadata, code coverage information, and screenshot results.

[0171] Among them, the target test cases are used to test the target user's page.

[0172] In one possible implementation, after testing the target user page using target test cases, the target code of the target user page can be restored to its original source code. It should be understood that since the target code may be modified from the source code, it is necessary to restore the target user page's code to its original source code after testing to ensure the correctness and reliability of the target user page.

[0173] In this embodiment, target metadata is randomly generated based on historical data from multiple interfaces of the target code, eliminating the need for testers to construct test data manually. By writing the target metadata into the global variable window of the target code, code containing the target metadata can be executed when the target code is run. If the probability of successful execution increases, it indicates that the number of lines of code successfully executed by the current target code has increased compared to historical code. Target test cases can then be generated based on the target metadata, code coverage information, and screenshot results, and testing can be performed using these target test cases. This achieves automated test case generation without the need for manual coding, improving testing efficiency. Furthermore, no coding is required; only the target metadata is randomly generated based on historical interface data, which can then be combined with the target code to generate test cases, avoiding errors from manual testing or coding and improving testing accuracy.

[0174] Based on the user page testing method provided in the above embodiments, in order to further improve the probability of successfully executing code, in one possible implementation, after obtaining the target test case, it may further include:

[0175] B1: Identify code that failed to execute based on code coverage information.

[0176] It should be understood that code coverage information can reflect code that failed to execute, and thus further optimize the code that failed to execute, so that the code that failed to execute can be executed successfully during the generation of new test cases.

[0177] B2: Determine the data range of the interface corresponding to the code that failed to execute.

[0178] Data range refers to the range of data input allowed by the interface. It should be understood that since the target metadata is generated randomly, its randomness may cause the generated data to not conform to the data range of a certain interface, thus causing the code corresponding to that interface to fail to execute. Therefore, the data range corresponding to the code that failed to execute can be determined, and then the target metadata can be generated in combination with the data range.

[0179] B3: Generate random data within the data range based on the historical interface data corresponding to the code that failed to execute; and generate random data based on the historical interface data corresponding to the code that executed successfully.

[0180] It should be understood that, in the embodiments of this application, for code that fails to execute, its data range can be determined, and metadata (i.e., data) can be generated within its data range based on the corresponding historical interface data; for code that executes successfully, metadata (i.e., data) can be generated directly based on the corresponding historical interface data. In this way, more accurate target test cases can be generated, improving the accuracy and reliability of testing.

[0181] B4: Use the generated data as new target metadata.

[0182] It should be understood that after generating metadata for the code that executes successfully and the code that does not execute successfully, the generated metadata is used as new target metadata, and the new target metadata is used to generate new target test cases.

[0183] As an example, suppose that after generating the target test cases, you can view code coverage information to identify the code in the target code that failed to execute successfully, such as... Figure 4a The code snippets a, b, and c are further analyzed. The successful execution of code a, b, and c depends on the value of the `presaleType` field, which originates from the target metadata.

[0184] Therefore, the metadata corresponding to codes a, b, and c can be adjusted by changing the relevant interface field `pre_sale_type` to an enumeration value and editing its possible enumeration values. For example, if `pre_sale_type` is 0, the `presaleType` of codes a, b, and c is FULL; if `pre_sale_type` is 1, the `presaleType` in codes a, b, and c is DEPOSITE; and if `pre_sale_type` is 2, the `presaleType` in codes a, b, and c is CROWD.

[0185] Therefore, the fields in the metadata corresponding to code a, code b, and code c can be modified to the enumeration value [0, 1, 2]. The randomly generated metadata will then be a value from [0, 1, 2]. If the amount of generated data is large enough (i.e., the value of N is set large enough), all enumerations will be matched, such as... Figure 4b The settings page shown. Figure 4c As shown, after generating new target metadata, the above user page test method is executed again, and the new target test cases can cover code a, code b, and code c.

[0186] In this way, by determining the data range of the interface corresponding to the code that failed to execute, the metadata of the code that failed to execute can be randomly generated based on historical interface data and data range, thereby improving the accuracy and reliability of the target test cases.

[0187] Based on the user page testing method provided in the above embodiments, in order to ensure that the final generated target test cases can cover all the code in the target code as much as possible, in one possible implementation, if the code coverage information corresponding to the new target metadata indicates that the probability of successfully executed code has increased, then the target metadata is updated according to the steps for determining the new target metadata, and test cases are regenerated; until the probability of successfully executed code indicated by the code coverage information remains unchanged, then the last generated test case is used as the target test case.

[0188] It should be understood that if the probability of successfully executed code indicated by the code coverage information increases, then the target metadata needs to be regenerated according to steps B1 to B4 above, and new test cases should be generated based on the regenerated target metadata to improve the coverage of the target code by the test cases; if the probability of successfully executed code indicated by the code coverage information remains unchanged, then it can be considered that the upper limit of coverage has been reached, and there is no need to regenerate it. The last generated test case can be used as the target test case.

[0189] In one possible implementation, to avoid the situation where the probability of code coverage information indicating successful execution remains unchanged due to chance, a preset number of times can be set. That is, within the preset number of times, if the probability of code coverage information indicating successful execution remains unchanged, then the last generated test case is used as the target test case.

[0190] This application embodiment improves the accuracy and reliability of test cases by optimizing target metadata using code coverage information.

[0191] In one possible implementation of the user page testing method provided in the above embodiments, after saving the target test cases, it may further include:

[0192] C1: Run the target test case and obtain the target test page corresponding to the target test case.

[0193] The target test page refers to the test page displayed after the target test cases are run.

[0194] It should be understood that after the code of the target user page is modified or when multiple rounds of testing are performed on the target user page, it is necessary to run target test cases to determine whether the code is normal. Therefore, in the embodiments of this application, when the code of the target user page is target code, the generated target test cases can be used to test the target user page.

[0195] C2: Compare the target test page with the historical test pages to obtain the comparison results.

[0196] Historical test pages are the test pages corresponding to historical test cases, which are test cases preceding the target test case. It should be understood that for a single target user page, multiple target test cases can be generated chronologically, and each target test case has a corresponding target test page. The previously generated target test case relative to the current target test case can be considered a historical test case, and the target test page corresponding to that historical test case is the historical test page. The historical test page can be a test page obtained by testing the target user page for the same target code, or it can be a test page obtained by testing the target code of a previous version of the target user page; no specific limitation is made here.

[0197] As an example, suppose the target user page needs to generate two target test cases, namely the first target test case and the second target test case. The first target test case is generated before the second target test case. Then the first target test case can be called the historical test case, and the target test page corresponding to the first target test case is the historical test page.

[0198] As another example, suppose the code of the target user page is updated from version 1 to version 2. The target test cases generated for version 1 of the target user page can be called historical test cases, and the corresponding test page obtained by running these historical test cases on the target user page of version 1 is called the historical test page. Similarly, the target test cases generated for version 2 of the target user page can be called target test cases, and the corresponding test page obtained by running these target test cases on the target user page of version 2 is called the target test page.

[0199] It should be understood that by comparing the target test page with the historical test page, it can be determined whether the two test pages are consistent, and thus whether the code modification is correct.

[0200] C3: If the comparison result indicates that the target test page is consistent with the historical test page, then the test ends.

[0201] If the target test page is the same as the historical test page, it indicates that the modified code is correct, or the code has not been modified and there are no exceptions, so the test can be ended.

[0202] C4: If the comparison result indicates that the target test page is inconsistent with the historical test page, it is recorded as an abnormal test case.

[0203] Combination Figure 5 As shown, Figure 5 This section displays historical test pages and the target test page. It assumes the test page comprises three parts: content A, content B, and content C. Figure 5 As can be seen, content A is displayed on the historical test page but not on the target test page; content B is in the same position on both the historical and target test pages; content C is below content B on the historical test page, while part of content C is above content B on the target test page. This comparison shows that the historical and target test pages are inconsistent, indicating that the modified code may not reflect the intended behavior and could potentially cause an anomaly. Therefore, this target test case can be recorded as an anomalous test case.

[0204] In one possible implementation, after identifying the abnormal test cases, it can be determined whether the abnormal test cases meet the target requirements; if the abnormal test cases meet the target requirements, new target test cases are generated; if the abnormal test cases do not meet the target requirements, the target code is modified.

[0205] The target requirement refers to the testing requirements for the target user page. For example, if a new button is added to the target user page for returning, and the target requirement is to test whether the target user page can fill in data, then the generated target test case is used to test whether the target user page can fill in data, and is unrelated to the newly added button. In other words, if this exception test case can meet the target requirement, then the exception can be ignored.

[0206] To ensure compatibility with newly added content on the target user page, if the exception test case meets the target requirements, a new target test case can be generated based on the modified target code. If the exception test case does not meet the target requirements, it indicates that the target code corresponding to the target user page may contain an exception caused by the code modification, and therefore the target code can be modified. This process enables testing of the user page.

[0207] In this embodiment of the application, testing the target user page using target test cases can improve the accuracy and reliability of the test, and the generation and maintenance of test cases are simple, thus increasing the testing speed.

[0208] Based on the user page testing method provided in the above embodiments, see [link to relevant documentation]. Figure 6 This figure is a schematic diagram of a user page testing process provided in an embodiment of this application. Combined with... Figure 6 As shown, the user page testing process provided in this application embodiment can be implemented based on a task tool, including:

[0209] Step 1: Delete the historical target test cases of the target user page based on the unique identifier of the target user page.

[0210] Each time a target user page is tested, a new target test case is generally generated, so historical target test cases can be deleted.

[0211] Step 2: Use the task tool to open the page address of the target user's page to be tested.

[0212] Specifically, the target page information can be obtained based on the unique identifier of the target user's page. This target page information may include target metadata and the target address of the target user's page.

[0213] It should be understood that, in the embodiments of this application, page testing can be performed using task tools, which improves testing efficiency compared to manual testing.

[0214] Step 3: Before the target user page is opened, generate random data as target metadata based on historical interface data; and inject the code required to generate test cases into the corresponding code of the target user page before the target user page is opened.

[0215] After generating the target metadata, it is necessary to write the target metadata into the global variable window of the target user page.

[0216] The code required to generate test cases may include, but is not limited to, code that proxies the target user's page input, code that collects API data, and coverage calculation code. Before the target user page opens, the code that proxies the target metadata input is injected into the target user page; before the target user page opens, the code that collects API data is injected into the target user page; and before the target user page opens, the coverage calculation code (including HTML code, CSS code, and JavaScript code) is injected into the target user page.

[0217] The code for collecting interface data is used to collect interface data from multiple interfaces, and can also collect interface data that is not present in the target metadata.

[0218] Step 4: Load the target user page.

[0219] It should be understood that after configuration, the task tool is used to load the target user's page to obtain relevant data, which is convenient for generating test cases later.

[0220] Step 5: During the loading of the target user's page, collect data and write it to the global variable window.

[0221] Specifically, the code that collects interface data collects interface data from multiple interfaces and writes it into the global variable window; during the loading of the target user page, it collects JavaScript code coverage information and writes it into the global variable window; after the target user page is loaded, it collects HTML and CSS code coverage information and writes it into the global variable window.

[0222] Step 6: After the target user page has loaded and the API data and code coverage information have been collected, inject a marker element into the target user page. This marker element is used to notify the task tool that the task for the target user page has been completed.

[0223] The process involves waiting for the marked elements to finish rendering in the task tool. It also involves retrieving API data collected from the global variable window of the target user's page, converting newly added API data into target metadata, and storing it. Finally, it involves retrieving and storing code coverage information from the global variable window of the target user's page.

[0224] Step 7: Determine if the code coverage information indicates an increased probability of successfully executing code.

[0225] If the probability of successfully executing the code increases, use the task tool to take a screenshot of the target user's page, and save the target metadata, screenshot results, code coverage information, unique identifier of the target user's page, and unique identifier of the target project as the target test case; if the coverage does not increase, adjust the target metadata and repeat steps 3-7 above until the probability of successfully executing the code does not increase within a preset number of times (e.g., N times), then end the process.

[0226] This application embodiment uses randomly generated target metadata to generate target test cases based on the target code of the target user page at the page level. This embodiment eliminates the need to construct input data and expected output data for a large number of functions, and also eliminates the need for manually writing and maintaining test cases, thus reducing development difficulty and improving testing efficiency.

[0227] Based on the user page testing process provided in the above embodiments, after generating the target test cases, refer to... Figure 7 This application also provides a user page testing process, which may include:

[0228] Step 1: Obtain all target test cases under the target project based on the unique identifier of the target project.

[0229] It should be understood that the target project includes multiple user pages, and each user page has a corresponding target user page. Therefore, the target project can include multiple target test cases.

[0230] Step 2: For each target test case, obtain the corresponding target page information based on the unique identifier of the target user page saved in the target test case.

[0231] Step 3: Based on the information of each target page, use the task tool to open the target address corresponding to all target test cases.

[0232] Step 4: Before each target user page is opened, write the target metadata from the target test case into the global variable window of the target code.

[0233] Step 5: Before each target user page is opened, inject the code entered using the target metadata proxy page into the corresponding target user page.

[0234] Step Six: On each target user's page, after the page has finished loading, inject the markup element into the target user's page.

[0235] This tag element is used to notify the target user of the task tool that the task on the page has been completed.

[0236] In this embodiment, the target test cases can be run directly, and it is only necessary to ensure that the project runs normally without the need for code instrumentation or other operations.

[0237] Step 7: Wait for the marked elements to finish rendering in the task tool.

[0238] Step 8: Use the task tool to take a screenshot of the target user's page to obtain the target test page, and compare the target test page with the historical test pages.

[0239] Step 9: If the target test page is different from the historical test page, it indicates that the target test case has failed, and the target test case is marked as an abnormal test case.

[0240] This requires storing the unique identifier of the abnormal test case and the corresponding target test page.

[0241] Step 10: Wait for all target test cases to finish executing.

[0242] After all target test cases under the target project have been executed, abnormal test cases can be viewed. If the abnormal test cases meet the new requirements (i.e., target requirements) changes, the abnormality can be ignored, and new target test cases can be generated and saved. If the abnormal test cases do not meet the new requirements changes, it indicates that there is a problem with the code, and testers need to modify the code. After the code is modified, the process of running the target test cases can be executed again.

[0243] Based on the user page testing method provided in the preceding embodiments, this application also provides a corresponding user page testing apparatus. The following, in conjunction with... Figure 8 Please provide an explanation. Figure 8 This is a schematic diagram of the user page testing device provided in an embodiment of this application. Figure 8 The user page testing device 800 shown may include:

[0244] The acquisition module 801 is used to acquire the target page information of the target user page; the target user page is any user page in the target project; the target page information includes target metadata, which is randomly generated based on historical interface data of multiple interfaces of the target code; the target code is the code of the target user page, which includes multiple lines of code.

[0245] The writing module 802 is used to write the target metadata into the global variable window of the target code; the global variable window includes variables corresponding to multiple interfaces, and the multiple variables correspond one-to-one with multiple data in the target metadata;

[0246] The execution module 803 is used to run the target code and obtain code coverage information; code coverage information represents the probability of successfully executing code in multiple lines of code;

[0247] The screenshot module 804 is used to take a screenshot of the page after the target code has finished running, if the code coverage information indicates that the probability of the code that was executed successfully has increased, and obtain the screenshot result.

[0248] The test case generation module 805 is used to generate target test cases based on target metadata, code coverage information, and screenshot results; the target test cases are used to test the target user page.

[0249] In one possible implementation, the target metadata generation module is used for:

[0250] Retrieve historical API data from multiple APIs, as well as the field types of those APIs;

[0251] Based on the historical interface data and field types of each interface, data corresponding to each interface is randomly generated.

[0252] Multiple data points are used as target metadata.

[0253] In one possible implementation, prior to writing module 802, the following is also included:

[0254] The coverage calculation code writing module 802 is used to write the coverage calculation code into the target code; the coverage calculation code is used to obtain the code coverage information of the target code.

[0255] In one possible implementation, after the test case generation module 805, a test case update module is also included, for:

[0256] Identify code that failed to execute based on code coverage information;

[0257] Determine the data range of the interface corresponding to the code that failed to execute;

[0258] Data is randomly generated within a data range based on historical interface data corresponding to the code that failed to execute; and data is randomly generated based on historical interface data corresponding to the code that executed successfully.

[0259] The generated data is used as new target metadata; the new target metadata is used to generate new target test cases.

[0260] In one possible implementation, the test case update module is also used to: if the code coverage information corresponding to the new target metadata indicates an increased probability of successfully executed code, then update the target metadata according to the determination steps of the new target metadata and regenerate test cases.

[0261] The last generated test case is used as the target test case until the probability of successful execution of the code indicated by the code coverage information remains constant.

[0262] In one possible implementation, following the test case generation module 805, a test module is also included, for:

[0263] Run the target test case to obtain the target test page corresponding to the target test case;

[0264] The test page is compared with the historical test pages to obtain the comparison results; the historical test page is the test page corresponding to the historical test case, and the historical test case is the test case before the target test case;

[0265] If the comparison result indicates that the test page is consistent with the historical test page, then the test ends;

[0266] If the comparison result indicates that the test page is inconsistent with the historical test page, it is recorded as an abnormal test case.

[0267] In one possible implementation, it also includes: a judgment module, used for:

[0268] Determine whether abnormal test cases meet the target requirements;

[0269] If the abnormal test case meets the target requirement, then a new target test case will be generated.

[0270] If the abnormal test cases do not meet the target requirements, the target code will be modified.

[0271] In one possible implementation, when the target code is run, it also includes: an interface data acquisition and update module, used for:

[0272] Obtain the interface data of multiple interfaces in the target code, and use it as multiple target interface data;

[0273] If new target interface data exists among multiple target interface data, convert the new target interface data into target metadata.

[0274] In one possible implementation, after testing the target user page using the target test cases, the following is also included:

[0275] The restore module is used to restore the target code of the target user page to the source code of the target user page.

[0276] The user page testing device provided in this application embodiment has the same beneficial effects as the user page testing method provided in the above embodiments, and therefore will not be described again.

[0277] The following sections will describe the structures for server-based and terminal-based configurations.

[0278] Figure 9 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 900 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 922 (e.g., one or more processors) and memory 932, and one or more storage media 930 (e.g., one or more mass storage devices) for storing application programs 942 or data 944. The memory 932 and storage media 930 can be temporary or persistent storage. The program stored in the storage media 930 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the server. Furthermore, the CPU 922 may be configured to communicate with the storage media 930 and execute the series of instruction operations in the storage media 930 on the server 900.

[0279] Server 900 may also include one or more power supplies 926, one or more wired or wireless network interfaces 950, one or more input / output interfaces 958, and / or one or more operating systems 941, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0280] CPU 922 is used to perform the following steps:

[0281] Obtain the target page information of the target user page; the target user page is any user page in the target project; the target page information includes target metadata, which is randomly generated based on historical interface data of multiple interfaces of the target code; the target code is the code of the target user page, which includes multiple lines of code.

[0282] Write the target metadata into the global variable window of the target code; the global variable window includes variables corresponding to multiple interfaces, and each variable corresponds one-to-one with multiple data in the target metadata;

[0283] Run the target code to obtain code coverage information; code coverage information represents the probability of successfully executing code among multiple lines of code;

[0284] After the target code finishes running, if the code coverage information indicates an increased probability of successfully executed code, then take a screenshot of the page after the target code finishes running and obtain the screenshot result.

[0285] Based on the target metadata, code coverage information, and screenshot results, target test cases are generated; these test cases are used to test the target user page.

[0286] This application also provides another embodiment, such as Figure 10 As shown, for ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application. The terminal can be any terminal device including mobile phones, tablets, personal digital assistants (PDAs), point-of-sale (POS) terminals, in-vehicle computers, etc. Taking a mobile phone as an example:

[0287] Figure 10 This is a block diagram illustrating a portion of the structure of a mobile phone related to the terminal provided in the embodiments of this application. (Reference) Figure 10 The mobile phone includes: a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a wireless fidelity (WiFi) module 1070, a processor 1080, and a power supply 1090, etc. Those skilled in the art will understand that... Figure 10 The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0288] The following is combined Figure 10 A detailed introduction to each component of a mobile phone:

[0289] The RF circuit 1010 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with the processor 1080; additionally, it transmits uplink data to the base station. Typically, the RF circuit 1010 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. Furthermore, the RF circuit 1010 can also communicate wirelessly with networks and other devices. The aforementioned wireless communications may use any communication standard or protocol, including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, and Short Messaging Service (SMS).

[0290] The memory 1020 can be used to store software programs and modules. The processor 1080 executes various mobile phone functions and data processing by running the software programs and modules stored in the memory 1020. The memory 1020 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 1020 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0291] The input unit 1030 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the mobile phone. Specifically, the input unit 1030 may include a touch panel 1031 and other input devices 1032. The touch panel 1031, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 1031), and drive the corresponding connection devices according to a pre-set program. Optionally, the touch panel 1031 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 1080, and can also receive and execute commands sent by the processor 1080. In addition, the touch panel 1031 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 1031, the input unit 1030 may also include other input devices 1032. Specifically, other input devices 1032 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0292] The display unit 1040 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 1040 may include a display panel 1041, which may optionally be configured as a liquid crystal display (LCD), organic light-emitting diode (OLED), or similar display panel 1041. Further, a touch panel 1031 may cover the display panel 1041. When the touch panel 1031 detects a touch operation on or near it, it transmits the information to the processor 1080 to determine the type of touch event. Subsequently, the processor 1080 provides corresponding visual output on the display panel 1041 according to the type of touch event. Although in Figure 10 In this embodiment, the touch panel 1031 and the display panel 1041 are two separate components to realize the input and output functions of the mobile phone. However, in some embodiments, the touch panel 1031 and the display panel 1041 can be integrated to realize the input and output functions of the mobile phone.

[0293] The mobile phone may also include at least one sensor 1050, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 1041 according to the ambient light level, and the proximity sensor can turn off the display panel 1041 and / or the backlight when the phone is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometer, taps), etc. Other sensors that may be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0294] The audio circuit 1060, speaker 1061, and microphone 1062 provide an audio interface between the user and the mobile phone. The audio circuit 1060 converts the received audio data into electrical signals and transmits them to the speaker 1061, where the speaker 1061 converts them into sound signals for output. On the other hand, the microphone 1062 converts the collected sound signals into electrical signals, which are then received by the audio circuit 1060, converted into audio data, and then processed by the processor 1080 before being transmitted via the RF circuit 1010 to, for example, another mobile phone, or the audio data can be output to the memory 1020 for further processing.

[0295] WiFi is a short-range wireless transmission technology. Through the WiFi module 1070, mobile phones can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 10 The WiFi module 1070 is shown, but it is understood that it is not an essential component of a mobile phone and can be omitted as needed without changing the essence of the invention.

[0296] The processor 1080 is the control center of the mobile phone, connecting various parts of the phone through various interfaces and lines. It executes software programs and / or modules stored in the memory 1020, and calls data stored in the memory 1020 to perform various functions and process data, thereby collecting overall data and information from the phone. Optionally, the processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user page, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1080.

[0297] The mobile phone also includes a power supply 1090 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 1080 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0298] Although not shown, mobile phones may also include a camera, Bluetooth module, etc., which will not be described in detail here.

[0299] In this embodiment of the application, the processor 1080 included in the terminal also has the following functions:

[0300] Obtain the target page information of the target user page; the target user page is any user page in the target project; the target page information includes target metadata, which is randomly generated based on historical interface data of multiple interfaces of the target code; the target code is the code of the target user page, which includes multiple lines of code.

[0301] Write the target metadata into the global variable window of the target code; the global variable window includes variables corresponding to multiple interfaces, and each variable corresponds one-to-one with multiple data in the target metadata;

[0302] Run the target code to obtain code coverage information; code coverage information represents the probability of successfully executing code among multiple lines of code;

[0303] After the target code finishes running, if the code coverage information indicates an increased probability of successfully executed code, then take a screenshot of the page after the target code finishes running and obtain the screenshot result.

[0304] Based on the target metadata, code coverage information, and screenshot results, target test cases are generated; these test cases are used to test the target user page.

[0305] This application also provides a computer-readable storage medium for storing program code that executes any one of the implementation methods of the user page testing method described in the foregoing embodiments.

[0306] This application also provides a computer program product including instructions that, when run on a computer, cause the computer to execute any one of the implementation methods of a user page testing method described in the foregoing embodiments.

[0307] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system and equipment described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0308] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of the system is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple systems may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0309] The system described as separate components may or may not be physically separate. Components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0310] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0311] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0312] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. < / h1>

Claims

1. A user page testing method, characterized in that, include: Obtain the target page information for the target user; The target user page can be any user page in the target project; The target page information includes target metadata, which is randomly generated based on historical interface data of multiple interfaces of the target code. The target code is the code of the target user page, and the target code includes multiple lines of code. Write the target metadata into the global variable window of the target code; The global variable window includes variables corresponding to each of the multiple interfaces, and the multiple variables correspond one-to-one with multiple data in the target metadata. Run the target code to obtain code coverage information; The code coverage information represents the probability that the code in the multiple lines of code will execute successfully; After the target code finishes running, if the code coverage information indicates an increased probability of successfully executed code, then a screenshot is taken of the page after the target code finishes running, and the screenshot result is obtained. Based on the target metadata, the code coverage information, and the screenshot results, generate target test cases; The target test cases are used to test the target user page.

2. The user page testing method according to claim 1, characterized in that, The target metadata is generated in the following way: Obtain historical interface data for the multiple interfaces, as well as the field types of the multiple interfaces; Based on the historical interface data and field types of each interface, data corresponding to each interface is randomly generated. Multiple data points are used as the target metadata.

3. The user page testing method according to claim 1, characterized in that, Before writing the target metadata into the global variable window of the target code, the method further includes: The coverage calculation code is written into the target code; the coverage calculation code is used to obtain the code coverage information of the target code.

4. The user page testing method according to claim 1, characterized in that, After obtaining the target test cases, the method further includes: Based on the code coverage information, identify the code that failed to execute; Determine the data range of the interface corresponding to the code that failed to execute; Based on the historical interface data of the interface corresponding to the code that failed to execute, data is randomly generated within the data range; and based on the historical interface data corresponding to the code that executed successfully, data is randomly generated. The generated data is used as new target metadata; the new target metadata is used to generate new target test cases.

5. The user page testing method according to claim 4, characterized in that, If the code coverage information corresponding to the new target metadata indicates an increased probability of successfully executed code, then the target metadata is updated according to the steps for determining the new target metadata, and test cases are regenerated. Until the probability of successfully executing code indicated by the code coverage information remains unchanged, the last generated test case will be used as the target test case.

6. The user page testing method according to claim 1, characterized in that, After saving the target test case, the method further includes: Run the target test case to obtain the target test page corresponding to the target test case; The target test page is compared with the historical test pages to obtain the comparison result; the historical test page is the test page corresponding to the historical test case, and the historical test case is the test case before the target test case; If the comparison result indicates that the target test page is consistent with the historical test page, then the test ends; If the comparison result indicates that the target test page is inconsistent with the historical test page, it is recorded as an abnormal test case.

7. The user page testing method according to claim 6, characterized in that, Also includes: Determine whether the abnormal test cases meet the target requirements; If the abnormal test case meets the target requirement, then a new target test case is generated. If the abnormal test cases do not meet the target requirements, the target code will be modified.

8. The user page testing method according to any one of claims 1-7, characterized in that, When running the target code, it also includes: Obtain the interface data of multiple interfaces of the target code, and use them as multiple target interface data; If new target interface data exists among the multiple target interface data, the new target interface data is converted into target metadata.

9. The user page testing method according to any one of claims 1-7, characterized in that, After testing the target user page using target test cases, the method further includes: The target code of the target user page is restored to the source code of the target user page.

10. A user page testing device, characterized in that, The device includes: The acquisition module is used to acquire target page information of the target user page; the target user page is any user page in the target project; the target page information includes target metadata, which is randomly generated based on historical interface data of multiple interfaces of the target code; the target code is the code of the target user page, and the target code includes multiple lines of code. A writing module is used to write the target metadata into the global variable window of the target code; the global variable window includes variables corresponding to each of the multiple interfaces, and the multiple variables correspond one-to-one with multiple data in the target metadata; The execution module is used to run the target code and obtain code coverage information; the code coverage information represents the probability of successfully executing code in the multiple lines of code; The screenshot module is used to take a screenshot of the page after the target code has finished running, if the code coverage information indicates that the probability of successfully executed code has increased, and obtain the screenshot result. The test case generation module is used to generate target test cases based on the target metadata, the code coverage information, and the screenshot results; the target test cases are used to test the target user page.

11. A computer device, characterized in that, The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the steps of the user page testing method according to any one of claims 1 to 9, based on the instructions in the program code.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for performing the steps of the user page testing method according to any one of claims 1 to 9.

13. A computer program product, characterized in that, Includes a computer program or instructions that, when executed, implement the steps of the user page testing method according to any one of claims 1 to 9.

Images