Webpage item testing method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a webpage item testing method, electronic equipment, a storage medium and a program product, and the method comprises the steps: monitoring an execution state of a test script corresponding to a to-be-tested webpage item through a Selenium tool, and when the execution state indicates that the execution of the test script is abnormal, executing the to-be-tested webpage item; acquiring first failure screenshot data of a current execution page acquired by calling a preset screenshot method by the Selenium tool; outputting the first failed screenshot data to a user under the condition that the execution of the test script is completed; the first failed screenshot data is used for positioning an abnormal part of the to-be-tested webpage item. By capturing the page screenshot when the execution of the test script is abnormal in real time, the test result can be quickly and clearly determined based on the page screenshot, and the abnormal part of the webpage item can be efficiently positioned.

Description

Technical Field

[0001] The present application relates to the field of automated testing technology, and in particular to a web page project testing method, electronic equipment, storage medium, and program product. Background Art

[0002] In today's digital age, the importance of software quality is self-evident. To ensure software quality and stability, automated testing has become an integral part of the software development process. Selenium, a widely used automated testing tool, has different tools and components that play a vital role in various testing scenarios. Selenium IDE is an integrated development environment (IDE) for browser automated testing. It quickly records user actions in the browser, such as clicks, input, and selections, and converts these actions into test steps. Specifically, Selenium IDE converts these actions into repeatable test scripts. Selenium Side Runner is a command-line tool that reads and executes test scripts generated by Selenium IDE and outputs test results. However, these outputs can be difficult to understand and use for testers unfamiliar with programming and data processing. In summary, Selenium IDE and Selenium Side Runner still have shortcomings in test result reporting, resulting in poor readability. The intuitive and efficient presentation of detailed test results has become a pressing issue. Summary of the Invention

[0003] The purpose of the embodiments of the present application is to provide a web page project testing method, electronic device, storage medium and program product to achieve the technical effect of intuitively and efficiently displaying test results.

[0004] A first aspect of an embodiment of the present application provides a webpage project testing method, the method comprising:

[0005] Monitoring the execution status of a test script corresponding to the web page project to be tested by a Selenium tool, and obtaining first failure screenshot data of the currently executed page collected by the Selenium tool by calling a preset screenshot method when the execution status indicates that the test script is executed abnormally;

[0006] When the test script is executed, the first failure screenshot data is output to the user; the first failure screenshot data is used to locate the abnormal part of the web page project to be tested.

[0007] In the above implementation process, by automatically capturing page screenshots in real time when the test script is executed abnormally, users can quickly determine the test results based on the page screenshots, and use the page screenshots to efficiently locate the abnormal part of the web page project, overcoming the problem that only outputting the original logs makes the test results unintuitive and it is difficult to locate the abnormal part of the web page project based on the original logs.

[0008] Furthermore, the web page project to be tested includes multiple web page module test items; each web page module test item includes at least one functional test item; the first failure screenshot data includes multiple; each first failure screenshot data has a corresponding relationship with the functional test item; the method further includes:

[0009] Determine a storage path for each first failure screenshot data, and store each first failure screenshot data in the corresponding storage path;

[0010] For each first failure screenshot data, determining an identifier of a first functional test item corresponding to the first failure screenshot data, and storing the identifier of the first functional test item corresponding to each first failure screenshot data and a corresponding storage path in a preset screenshot array;

[0011] The outputting the first failure screenshot data to the user includes:

[0012] A screenshot display instruction carrying a target identifier is obtained, a target storage path is determined from the screenshot array based on the target identifier, and first failed screenshot data stored in the target storage path is output to a user.

[0013] In the above implementation process, by utilizing the correspondence between screenshot data and functional test items, users can quickly obtain screenshot data under the functional test items based on the identifiers of the functional test items, thereby accurately locating the abnormal parts of the web page items based on the functional test items where the screenshot data exists, thereby improving the efficiency of test result acquisition and analysis.

[0014] Furthermore, the web page project to be tested includes a plurality of web page module test items; each web page module test item includes at least one function test item; the method further includes:

[0015] Obtaining the test result for the test script output by the Selenium tool, and deserializing the test result into a structured parsing result;

[0016] Obtain a structured object to be filled; the fields of the structured object to be filled include the total number of project function test items to be filled, the number of passed project function test items to be filled, and the array of failed project function test items to be filled;

[0017] Filling the total number of project functional test items to be filled in according to the total use case number field in the parsing result, filling the passed number of project functional test items to be filled in according to the status field of each functional test item in the parsing result, determining the first functional test item that failed the test according to the status field of each functional test item in the parsing result, and filling the project functional test item failure array based on a first failure screenshot data set corresponding to the first functional test item and a failure reason; wherein the first failure screenshot data set includes the first failure screenshot data;

[0018] Determining a first test pass rate of the webpage item to be tested based on the total number of filled item function test items in the filled structured object and the number of passed filled item function test items;

[0019] Outputting the first failure screenshot data set and the failure reason in the project function test item failure array and the first test pass rate to the user.

[0020] In the above implementation process, the test results in the original format are deserialized into structured objects, and statistical indicators of project-level test results are automatically generated, such as the project's pass rate. At the same time, details of failed functional test items are generated, realizing a quantitative and intuitive display of test results.

[0021] Furthermore, the fields of the structured object to be filled also include the test results of each webpage module test item to be filled; the test results of each webpage module test item to be filled include the total number of module function tests to be filled, the total number of module function test passes to be filled, and the array of module function test failures to be filled; the method further includes:

[0022] For each web page module test item, determine the target functional test items included in the web page module test item from the web page module test item field to which each functional test item belongs in the parsing result, fill in the total module functional test items to be filled in the web page module test item according to the number of the target functional test items, determine the total module functional test pass items and module failed functional test items to be filled in the web page module test item according to the status field of the target functional test item, and fill in the module functional test failure array to be filled based on the second failure screenshot data set of the module failed functional test item; wherein, the first failure screenshot data set includes the second failure screenshot data set;

[0023] For each webpage module test item, determining a second test pass rate for each webpage module test item based on the total number of module function tests after filling and the total number of passed module function tests after filling;

[0024] The second failure screenshot data set in the module function test failure array and the second test pass rate are output to the user.

[0025] In the above implementation process, the test results are refined to the module level, and the test pass rate of each module is calculated and output, which intuitively shows the user the test status of each module included in the web project.

[0026] Furthermore, the first failure screenshot data set, the failure reason, the first test pass rate, the second failure screenshot data set, and the second test pass rate are output to the user through a Node.js interface.

[0027] In the above implementation process, detailed and intuitive multi-dimensional test results are output through the Node.js interface, which overcomes the difficulty for non-technical personnel to interpret the original test result data (such as JSON test result files).

[0028] Furthermore, the method further comprises:

[0029] receiving an assertion insertion instruction, wherein the assertion insertion instruction is used to instruct the Selenium tool to insert an assertion statement at a target location in the test script; the assertion statement is used to instruct to terminate execution of the test script at the target location;

[0030] According to the execution status of the test script before the target position, the code statement where the exception occurs in the test script is determined.

[0031] In the above implementation process, assertion statements are dynamically inserted into the test script to accurately locate the code position that causes the test failure.

[0032] Furthermore, the screenshot method includes the driver.takeScreenshot() method; and the format of the first failed screenshot data includes a base64 encoding format.

[0033] In the above implementation process, the base64-encoded screenshot format can overcome the poor compatibility of traditional screenshot data and ensure that the test results can be seamlessly integrated into the visualization platform.

[0034] According to a second aspect of an embodiment of the present application, an electronic device is provided, comprising:

[0035] processor;

[0036] a memory for storing processor-executable instructions;

[0037] Wherein, when the processor calls the executable instruction, any method described in the first aspect is implemented.

[0038] A third aspect of an embodiment of the present application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first aspect.

[0039] A fourth aspect of the embodiments of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements any method described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0041] Figure 1 A flowchart of a web page project testing method provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of an overall process provided in an embodiment of the present application;

[0043] Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0045] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0046] In related technologies, Selenium Side Runner reads and executes test scripts generated by Selenium IDE and outputs a JSON file containing the test results. However, further processing and analysis of the JSON file is required to obtain useful test result information, which can be challenging for testers unfamiliar with programming and data processing. Specifically, when using Selenium tools for automated testing of web projects, the test results are generally output in JavaScript object notation format, also known as JSON. JSON-formatted test result data often only contains raw fields such as test item execution status and error logs, lacking multi-dimensional statistical information (such as project pass rate and module failure rate) and visualization capabilities. Testers must manually parse the JSON file and write scripts to generate reports to clearly understand the test results, resulting in inefficient locating of anomalies. In addition to being unintuitive, test results in this format cannot be directly linked to a continuous integration platform or test management system, making them difficult to store, integrate, or display. Furthermore, they lack the ability to compare and analyze historical test results, making it difficult to locate program defects by analyzing the differences in test results from multiple versions.

[0047] At the same time, failure screenshots, a crucial component of test results, are typically captured through a screenshot log function in related technologies. However, this function uses a fixed path to store screenshot files, which lacks correlation with functional test items. This makes it impossible to aggregate failed screenshots by module, forcing testers to traverse all screenshot files to locate the issue, which is extremely inefficient in multi-module, large-scale testing scenarios. In summary, related technologies have significant shortcomings in terms of test result visualization, and an intuitive and efficient test result display method is urgently needed.

[0048] In response to any of the above-mentioned issues, the present application provides a web page project testing method, referring to Figure 1 , Figure 1 A flowchart of a web page project testing method provided in an embodiment of the present application.

[0049] In this embodiment, the method includes:

[0050] Step S10: monitoring the execution status of the test script corresponding to the web page project to be tested by the Selenium tool, and when the execution status indicates that the test script is executed abnormally, obtaining first failure screenshot data of the current execution page collected by the Selenium tool by calling a preset screenshot method;

[0051] It's important to note that Selenium is a tool for testing web applications. Selenium tests run directly in the browser, just like real users. Supported browsers include Internet Explorer, Mozilla Firefox, Safari, Google Chrome, Opera, and Edge. Selenium's main functions include testing browser compatibility—that is, testing an application to see if it works well across different browsers and operating systems. Selenium also supports automatic action recording and the generation of test scripts in languages ​​like .NET, Java, and Perl.

[0052] Selenium tools include Selenium IDE, Selenium Side Runner, etc.

[0053] The web page project to be tested refers to the web application or website that is automated tested using the Selenium tool. Specifically, it can refer to the backend management system, web application, e-commerce website, etc.

[0054] A test script refers to the automated test code for the web project (such as login and order process test cases).

[0055] Selenium's monitoring covers all operations of the test script on the web project, such as page navigation, element operation, form submission and other operations.

[0056] It should be understood that the Selenium tool tracks the execution flow of the test script in real time to determine whether all operations are completed as expected. When an unhandled exception occurs during the test script execution (such as an element click interception exception, an element non-interaction exception, or an element non-selectability exception), Selenium will mark the execution status as "Exception" to determine whether the test script has executed abnormally. Since functional defects in the web project will cause test script execution abnormalities, execution abnormalities point to functional defects in the web project.

[0057] The first failure screenshot data can be data in a format such as png or base64. This embodiment is described by taking the first failure screenshot data as a png picture as an example. One or more first failure screenshot data can be collected during the test process.

[0058] You can take a screenshot of the currently executing page by calling Selenium's built-in screenshot API (such as driver.takeScreenshot()) or encapsulating custom screenshot logic (such as a full-screen screenshot with local element highlighting). Execute the screenshot method immediately after an exception is triggered to ensure that the page state is captured closest to the time the error occurred. For example, if the page does not redirect after clicking an element, the screenshot should include the unresponsive button and the current URL.

[0059] For example, take the test script as an example of online form submission function test. When the test script is executed, Selenium detects the button click and waits for the server response. If the server returns a 500 error, Selenium marks it as "execution exception" and records the log, which then triggers the subsequent screenshot collection step, that is, collecting screenshot data through the driver.takeScreenshot() method. It is understandable that regarding the driver.takeScreenshot() method: in Selenium, the screenshot function is implemented through the TakesScreenshot interface. All browser drivers (such as ChromeDriver, FirefoxDriver) support this interface, so screenshots can be obtained through the driver.getScreenshotAs(OutputType type) method. Among them, OutputType.FILE is directly saved as a PNG file; OutputType.BASE64 returns the Base64 encoded string of PNG; OutputType.BYTES returns the binary data of PNG. Selenium generates PNG format screenshots by default.

[0060] Alternatively, obtain the test script for the web project to be tested by following these steps: First, install Selenium IDE from your browser's add-on store and launch it by finding it in your browser's extensions list. Next, select "Create a new project," name it, and choose a storage location based on your project requirements. Then, on the Selenium IDE main interface, find the red, circular "Record" button and click it to start recording. Selenium IDE will then begin monitoring browser operations. Now, perform the actions you want to record in the browser, such as opening a specific web page, clicking buttons, links, and other elements on the page, entering text in an input box, selecting a drop-down menu, and so on. At the same time, pay attention to the consistency and logic of the actions to ensure that the recorded test scenario meets actual requirements. If the operation involves loading a page or waiting for a specific element to appear, you can manually set a wait time. In the Selenium IDE command list, find the "Wait" command and specify the wait time by setting a time parameter. For example, "Wait 5000" means waiting for 5 seconds. After completing the operation process, click the red circular "Stop" button on the Selenium IDE interface to stop recording. After recording stops, Selenium IDE automatically generates the recorded test script and displays it in the "Commands" column on the main interface. Users can perform the following operations on the script: ① Check the accuracy of the commands to ensure that each operation is recorded correctly; ② Add comments to improve the readability of the script; ③ Set assertions to verify whether specific conditions are met, such as whether specific text appears on the page or whether an element exists; ④ Modify command parameters to adapt to different test scenarios. Then, in Selenium IDE, click the green triangle "Play" button to run the recorded test script. Observe the test process to check for errors or abnormalities. Based on the results, you can further adjust and optimize the test script. Finally, after editing and optimizing the test script, save the project. Selenium IDE supports exporting test scripts to multiple formats, such as code in programming languages ​​such as Java, Python, and C#, for use in different test frameworks. In this example, the test script is saved as the default side file.

[0061] In the specific implementation, a common object is used to simulate a hash table-like function, storing the association between failed cases and corresponding failure screenshot paths. The object key can be the unique identifier of the failed case, such as the case name or a unique number, here referred to as caseId. The corresponding value is the file path string of the failure screenshot corresponding to the failed case stored in a specified directory, for example, ' / path / to / screenshots / failure_case_1.png'. This allows the object property access method (failureScreenshotObj[caseId]) to quickly and easily obtain the failure screenshot path corresponding to a specific failed case, facilitating subsequent failure screenshot retrieval and use in operations such as generating test result reports. Furthermore, an array, failureCases, is defined, whose elements are objects containing case-related information and screenshot paths. The push method can be used to add the name, description, and corresponding screenshot path information of each failed case to the array as an object. For example, the screenshot data is stored in the array in association with the case ID, module to which the case belongs, exception type, and timestamp. Later, when generating a test result report or querying related failure case information, you can perform corresponding operations by traversing the array. This structure makes it easier to manage and process multiple failure cases as a whole.

[0062] Step S20: When the test script is executed, the first failure screenshot data is output to the user; the first failure screenshot data is used to locate the abnormal part of the web page project to be tested.

[0063] Optionally, when the test script is executed, all the failure screenshots or some of the failure screenshots stored in the associated array failureCases are read from the database or file system and displayed to the user, such as by the name of the test case or a unique number of the test case, and all the failure screenshots collected during the test are aggregated and displayed. In addition, the failure screenshots can be output to the user together with other types of test results (such as test pass rate, conclusion of test success, conclusion of test failure, reason for failure). In the case where only one type of test result, a failure screenshot, needs to be output, only failure screenshots in formats such as png or base64 can be output to the user. This embodiment is explained by outputting the first failure screenshot data in the image format of png to the user as an example. In the case where it is necessary to output multiple types of multi-dimensional test results including failure screenshots, an interactive report containing thumbnails of failure screenshots can be generated, and other types of test results can be reflected in this interactive report.

[0064] It should be noted that compared to traditional logs, screenshot data can provide three-dimensional positioning information, including spatial dimensions (the location of abnormal elements on the page, such as the coordinates of a missing button), temporal dimensions (the dynamic state of the page when the abnormality occurs, such as whether the loading spinner disappears), and contextual dimensions (the positional relationship of other elements surrounding the abnormality, such as the error prompt box). This means that testers or users do not need to speculate on the problem through logs, but can directly observe the abnormal performance through screenshots and locate the abnormal part of the web page project. For example, if the screenshot shows that the "Submit Button" is blocked, it can be located to a CSS layout problem; if the screenshot shows a "404 page", it can be located to a backend interface path configuration error.

[0065] In this embodiment, when a test script executes abnormally, a preset method is automatically called to capture screenshots of the page. After the test is complete, these screenshots are associated with the corresponding test case, module, and other information and output. This allows the test results to be displayed in a more intuitive graphical format, no longer limited to log text. This improves the readability of the test results and the efficiency of problem identification. Users or testers no longer need to analyze the log text line by line; they can simply browse the screenshots to quickly identify intuitive problems such as missing page elements and disorganized layouts, greatly shortening the time it takes to locate abnormal parts of a web page project.

[0066] Based on any of the above embodiments, the web page project to be tested includes multiple web page module test items; each web page module test item includes at least one functional test item; the first failure screenshot data includes multiple items; each first failure screenshot data has a corresponding relationship with the functional test item; the method further includes:

[0067] Determine a storage path for each first failure screenshot data, and store each first failure screenshot data in the corresponding storage path;

[0068] It is understandable that the web page module test item refers to an independent functional module in the web page project, such as a user authentication module and an order management module. A functional test item (equivalent to the above-mentioned test case) refers to a specific functional point in the web page module test item, such as a login function, a search function, and a payment function. The web page project is equivalent to a first-level directory, the web page module test item is equivalent to a second-level directory, and the functional test item is equivalent to a third-level directory. In this embodiment, the first failure screenshot data includes multiple, and one functional test item includes one or more first failure screenshot data.

[0069] It should be noted that in the relevant technology, the browser page is often screenshoted through the screenshot log function and stored in the test results. However, when collecting the first failure screenshot data through the screenshot log function, there is a problem that the screenshot storage path cannot be dynamically adjusted. Specifically: the screenshot log function usually relies on the path rules preset by the framework, such as . / screenshots / test_fail_123.png, and the user cannot dynamically adjust the path, such as by test module, environment, and timestamp classification. If it is necessary to classify and store by user role, such as admin_login_fail_20240101.png or browser type, such as chrome_120_fail.png, the screenshot log function is difficult to implement. However, the preset screenshot method provided in this embodiment (i.e., driver.takeScreenshot() method) can fully control the path through code, such as . / results / ${env} / ${testId}_${timestamp}.png, and the user or tester can specify the storage path of the first failure screenshot data, and supports dynamic naming to avoid overwriting. That is to say, the difference in storage path between the screenshot log function and the preset screenshot method provided by this embodiment lies at the core in the essential difference between dynamic generation strategy and static configuration. The screenshot log function adopts a hard-coded path, and directly defines the screenshot save path (such as / screenshots / ) and file name (such as screenshot_20241121.png) in the code. All screenshots are stored in the same directory. As the number of test cases increases, the number of files explodes and is difficult to manage. Moreover, the file name only contains a timestamp and cannot be associated with the test case or module information. The location of the abnormal part requires manual comparison of the log. However, when calling driver.takeScreenshot(), the storage path is dynamically generated by the program (such as in combination with environment variables, modules or exception types), rather than a hard-coded fixed path, so that the screenshot save location can be adaptively adjusted according to the test scenario, thereby solving the problem that the screenshot storage path of the screenshot log function cannot be dynamically adjusted.

[0070] For each first failure screenshot data, determining an identifier of a first functional test item corresponding to the first failure screenshot data, and storing the identifier of the first functional test item corresponding to each first failure screenshot data and a corresponding storage path in a preset screenshot array;

[0071] It should be noted that the identifier may refer to the ID or name of the test case, etc., and this embodiment does not impose any limitation on this.

[0072] In the specific implementation, for each first failed screenshot, the use case ID is used as the key and the screenshot storage path is stored as the value in the failureScreenshotObj object, thereby establishing an association between the failed use case and the screenshot. An array called failureCases is defined, with each element being an object containing use case-related information and screenshot paths. The name, description, and corresponding screenshot path of each failed use case are added to the array as objects using the push method. When generating test results later, you can directly traverse this array to quickly locate and categorize the associated screenshots by use case ID.

[0073] The outputting the first failure screenshot data to the user includes:

[0074] A screenshot display instruction carrying a target identifier is obtained, a target storage path is determined from the screenshot array based on the target identifier, and first failed screenshot data stored in the target storage path is output to a user.

[0075] Specifically, the user or the test framework initiates a screenshot display command (such as clicking the "View Failed Screenshots" button in the test result report). This command carries the identifier of the functional test item, retrieves the corresponding target storage path from the screenshot array, loads the screenshot data from the target storage path, and displays the screenshot data to the user, or embeds the screenshot data in the test result report and displays it to the user. Through the identifier-driven path resolution mechanism, on-demand rendering of failed screenshots is achieved, and the target screenshot can be quickly located, improving the efficiency of screenshot search.

[0076] In this embodiment, by establishing an association between functional test items and failed screenshot data, modular classification display and on-demand dynamic rendering of test results are achieved, thereby improving the efficiency of screenshot retrieval and the efficiency of abnormal part positioning.

[0077] Based on any of the above embodiments, the web page project to be tested includes multiple web page module test items; each web page module test item includes at least one function test item; the method further includes:

[0078] Obtaining the test result for the test script output by the Selenium tool, and deserializing the test result into a structured parsing result;

[0079] It should be noted that the test result of the test script refers to the test result file, that is, the JSON file.

[0080] Deserialize the JSON file into a structured JavaScript object using JSON.parse.

[0081] Specifically, after the test is completed, Selenium Side Runner will generate a JSON file in the output directory specified by the test result file to record the detailed results of the test. Once the JSON file of the test results is obtained, the interface written by NodeJS begins to play a role. Specifically as follows: First, it is necessary to introduce the fs module for file reading operations in Node.js (optionally, use the promises API to facilitate the processing of asynchronous operations) and a module for processing JSON data parsing. Second, define a function for reading and parsing files, which is used to read the JSON test result file of the specified path and extract key information from it. The implementation is as follows: first, use await fs.readFile to read the file content of the specified path, and parse it into an operable JavaScript object through JSON.parse, that is, the parsed result.

[0082] Obtain a structured object to be filled; the fields of the structured object to be filled include the total number of project function test items to be filled, the number of passed project function test items to be filled, and the array of failed project function test items to be filled;

[0083] It should be noted that initializing the overallResults object will obtain the structured object to be filled. The initialized overallResults object (i.e., the structured object to be filled) is used to store the overall test result information, including the total number of use cases (i.e., the total number of project functional test items), the number of passed use cases (i.e., the number of passed project functional test items), and the array of failed use cases (i.e., the array of failed project functional test items).

[0084] Filling the total number of project functional test items to be filled in according to the total use case number field in the parsing result, filling the passed number of project functional test items to be filled in according to the status field of each functional test item in the parsing result, determining the first functional test item that failed the test according to the status field of each functional test item in the parsing result, and filling the project functional test item failure array based on a first failure screenshot data set corresponding to the first functional test item and a failure reason; wherein the first failure screenshot data set includes the first failure screenshot data;

[0085] In the specific implementation, each test case in the JSON data is traversed, the total number of cases is counted, and the number of passed cases is updated according to the status of the case (this field in JSON indicates whether the case test passes or not, that is, the status field). For the failed case, its name, failure reason and failure screenshot path are extracted and added to the failure array of the project functional test item.

[0086] It should be noted that the failure screenshot data and failure reasons corresponding to all failed functional test items need to be added to the project functional test item failure array, so that the screenshots and failure reasons corresponding to the failed functional test items under the project can be quickly retrieved later.

[0087] It should be understood that when a webpage project has a functional defect, it will cause a test failure, which in turn will cause a script execution exception. Therefore, both the test failure and the execution exception point to the functional defect of the webpage project.

[0088] Determining a first test pass rate of the webpage item to be tested based on the total number of filled item function test items in the filled structured object and the number of passed filled item function test items;

[0089] In the specific implementation, define a function calculateOverallPassRate to calculate the overall test pass rate of the webpage project (i.e., the first test pass rate), which receives the overallResults object obtained after reading the file and parsing it as a parameter. The specific implementation is as follows:

[0090]

[0091]

[0092] This function gets the pass rate as a percentage by dividing the number of passed cases passedCases by the total number of cases totalCases and multiplying the result by 100. It then uses the toFixed(2) method to round the result to two decimal places to display the pass rate in a more standardized manner.

[0093] Outputting the first failure screenshot data set and the failure reason in the project function test item failure array and the first test pass rate to the user.

[0094] Specifically, all the first failed screenshot data during the test process, the failure reasons of the functional test items to which the first failed screenshot data belongs, and the overall test pass rate of the web page project are output to the user, providing powerful quantitative indicators for the evaluation of test quality and facilitating subsequent analysis and decision-making by testers.

[0095] In this embodiment, the test results in the original format are deserialized into structured objects, and statistical indicators of project-level test results are automatically generated, such as the pass rate of the project, and details of failed functional test items are generated, thereby achieving quantitative and intuitive display of test results.

[0096] Based on any of the above embodiments, the fields of the structured object to be filled further include the test results of each webpage module test item to be filled; the test results of each webpage module test item to be filled include the total module function test items to be filled, the total module function test pass items to be filled, and the module function test failure array to be filled; the method further includes:

[0097] For each web page module test item, determine the target functional test items included in the web page module test item from the web page module test item field to which each functional test item belongs in the parsing result, fill in the total module functional test items to be filled in the web page module test item according to the number of the target functional test items, determine the total module functional test pass items and module failed functional test items to be filled in the web page module test item according to the status field of the target functional test item, and fill in the module functional test failure array to be filled based on the second failure screenshot data set of the module failed functional test item; wherein, the first failure screenshot data set includes the second failure screenshot data set;

[0098] It is understandable that the tester will design test cases (i.e., the functional test items) based on the business processes and functional modules of the management system. For example, for the user management module, test cases such as user creation, modification, deletion, and query may be designed; for the authority management module, operation test cases for users with different permissions may be designed. By determining and outputting the test results of each module (i.e., the test results of each web page module test item), the test results presented by the entire test can be made clear at a glance, making it convenient for the test team members to quickly understand the overall situation of the test. The tester can clearly see the test results of the module he is responsible for and take appropriate measures to repair the problem in a timely manner. Among them, when classifying and counting the modules to which the test cases belong, if the module does not exist, the test result object of the corresponding module is initialized, the total number of use cases of the module is updated (i.e., the total number of module functional tests), the number of passed use cases (i.e., the total number of module functional tests passed), and the failed use case information is recorded (i.e., the module functional test failure array is updated). The failed screenshot data corresponding to the failed functional test items contained in all modules need to be added to the module functional test failure array so that the screenshot data corresponding to the failed functional test items under the module can be quickly retrieved and obtained later.

[0099] As an example, the module field in the parsing result is used to classify the functional test items into corresponding web page module test items, thereby determining the target functional test items included in each web page module test item. The total number of functional test items contained in each module is counted to determine the total number of module functional test items. The passed items and failed items are distinguished according to the status field of the functional test items to determine the module passed functional test items and the module failed functional test items. Based on the number of module passed functional test items, the total number of module functional test passed items is determined and filled in to obtain the total number of module functional test passed items after filling in, and the failure screenshot data of the module failed functional test items is extracted to construct a failure array.

[0100] It should be noted that the failed functional test items of all modules constitute all failed functional test items of the project. Therefore, the first failed screenshot data set of the project includes the second failed screenshot data set of the module.

[0101] For each webpage module test item, determining a second test pass rate for each webpage module test item based on the total number of module function tests after filling and the total number of passed module function tests after filling;

[0102] In the specific implementation, define the function calculateModulePassRates to calculate the test pass rate of each module (i.e., the second test pass rate), and operate based on the overallResults object obtained by reading the file previously. This function traverses each module in the modules attribute in the overallResults object. For each module, determine whether its total number of use cases is 0. If it is 0, set the module test pass rate to 0. Otherwise, calculate the module test pass rate by dividing the number of pass cases by the total number of use cases and multiplying it by 100 with two decimal places. Use the module name as the key and the test pass rate value as the value to store in the modulePassRates object. Finally, return this object containing the test pass rate of each module. The specific implementation is as follows:

[0103]

[0104]

[0105] This function gets the pass rate as a percentage by dividing the number of passed cases passedCases by the total number of cases totalCases, multiplying the result by 100, and using the toFixed(2) method to round the result to two decimal places.

[0106] The second failure screenshot data set in the module function test failure array and the second test pass rate are output to the user.

[0107] It should be noted that in addition to outputting to the user the second test pass rate corresponding to each module and the failure screenshot data corresponding to the functional test items that failed to be tested under each module, the failure reasons of the functional test items that failed to be tested can also be output to the user, so that the user or tester can intuitively see the failure reasons and failure screenshot data of the functional test items that failed to be tested under a certain module without obtaining the overall test results of the project (including the failure reasons and failure screenshot data of the functional test items that failed to be tested under the project).

[0108] In this embodiment, the test results are refined to the module level, the test pass rate of each module is calculated and output, and the test status of each module included in the web page project is intuitively displayed to the user.

[0109] Based on any of the above embodiments, the first failure screenshot data set, the failure reason, the first test pass rate, the second failure screenshot data set, and the second test pass rate are output to the user through a Node.js interface.

[0110] It should be understood that Node.js is an ideal choice for building high-performance Web applications because of its non-blocking I / O and event-driven model, which makes the development of high-concurrency services more efficient. In Web development, API (application programming interface) is a bridge for communication between systems. Whether it is the interaction between the front-end and the back-end, or the data transfer between microservices, the API interface plays an important role. In this embodiment, Node.js is used to build an API interface, and the test results of the JSON file output by the back-end Selenium Side Runner executing the test script are parsed and extracted to obtain failure screenshots, failure reasons, and test pass rate, and then rendered to the front-end through the interface written by Node.js to be displayed to the user. In addition to failure screenshots, failure reasons, and test pass rate, the module / function, script / use case, person in charge, receivable, and status can also be parsed and extracted from the test results of the JSON file, and rendered to the front end through the interface written in Node.js for display to the user. Among them, if a module corresponds to a test script, and a web page project to be tested includes multiple modules, then a web page project to be tested includes multiple test scripts, then the module / function is used to represent the specific module corresponding to the test script and the functional details included in the module; the script / use case is used to indicate the test script and the test case; the person in charge is used to indicate the test person in charge of each module or each test case; receivable is used to indicate whether a module or a test case must pass, and if it fails, it will affect the deployment and operation of the web project; the status is used to indicate the test status of the module or test case, for example, displaying states such as "in progress", "completed", and "failed".

[0111] In this embodiment, the front end renders important information such as modules / functions, scripts / use cases, pass rate, responsible person, receivable, status, failure reasons, and failure screenshots onto the page for display by calling an interface written by Node.js. This display method makes the test results clear at a glance, making it convenient for test team members to quickly understand the overall situation of the test. The responsible person can clearly see the test results of the module he is responsible for and take appropriate measures to fix the problem in a timely manner. The display of the receivable status allows the test team to quickly determine whether the test results meet expectations, and the display of the failure reasons and failure screenshots provides specific clues and intuitive evidence for problem investigation and resolution.

[0112] Based on any of the above embodiments, the method further includes:

[0113] receiving an assertion insertion instruction, wherein the assertion insertion instruction is used to instruct the Selenium tool to insert an assertion statement at a target location in the test script; the assertion statement is used to instruct to terminate execution of the test script at the target location;

[0114] According to the execution status of the test script before the target position, the code statement where the exception occurs in the test script is determined.

[0115] It's important to note that, based on the output failure reason, users or testers can roughly determine the functional steps of the failed test item that caused the failure. They can then add assertions after these steps and retest all steps before the assertion. Ultimately, the actual abnormal step can be pinpointed based on the success or failure of the test results. By injecting assertions and conducting secondary testing, test scripts can be precisely located, optimizing global debugging for targeted diagnosis and improving troubleshooting efficiency.

[0116] Specifically, the assertion insertion instruction can be input by the tester or user, or generated by an automated program. The purpose of inserting the assertion statement is to narrow the scope of the test script for the secondary test. Based on whether the secondary execution status of the test script segment before the assertion statement is abnormal, the abnormal code statement can be finally determined. If the test script segment before the assertion statement executes abnormally, then it can be determined that the abnormality occurred in this part of the test script segment, rather than the test script segment after the assertion statement.

[0117] In this embodiment, by dynamically inserting assertion statements into the test script, the code location that causes the test failure can be accurately located, greatly improving the efficiency of exception troubleshooting.

[0118] Based on any of the above embodiments, the screenshot method includes the driver.takeScreenshot() method; and the format of the first failed screenshot data includes a base64 encoding format.

[0119] It should be noted that in related technologies, screenshot data is often obtained through Nightwatch's failure screenshot function. The difference between Nightwatch and driver.takeScreenshot() is that Nightwatch only supports specific screenshot formats (such as PNG), while the driver.takeScreenshot() method returns screenshot data in base64 encoding format by default. In addition, because the framework design of Nightwatch's failure screenshot function is positioned to pursue standardization and simplified configuration in test result management, the screenshot path is hard-coded into a fixed directory to lower the usage threshold. However, driver.takeScreenshot(), as the underlying WebDriver method, directly returns the original Base64 data stream, leaving the path control entirely to the user code, thus supporting advanced customization such as dynamic paths and format conversion. Based on this, it can be seen that Nightwatch's failure screenshot function usually saves screenshots in a fixed folder, which may make the management of screenshot files complicated in a multi-user or multi-project environment, and prone to naming conflicts or file overwriting problems. The driver.takeScreenshot() method returns the screenshot data in base64-encoded format, which means that the screenshot data can be stored directly as a string in a database, log file, or anywhere else you need it, without having to worry about file naming conflicts or overwriting. At the same time, although driver.takeScreenshot() returns a base64-encoded string, this string can be easily converted to any desired image format (such as PNG, JPEG, etc.) to display the failed screenshot data in image format to the user.

[0120] It is understandable that the format of the first failure screenshot data in this embodiment also includes PNG, JPEG and other formats.

[0121] In this embodiment, the driver.takeScreenshot() screenshot method is used to obtain a failure screenshot in base64 encoding format, and the failure screenshot is stored in a path specified by the user or tester, overcoming the path dependency problem of previous screenshot storage.

[0122] In addition, in order to solve the problem that the automated test results are not intuitive, the efficiency and quality of software testing can be effectively improved. Figure 2 , Figure 2An overall flow chart of an embodiment of the present application is provided.

[0123] In this embodiment, Selenium IDE technology is used to record and replay test cases, and Selenium Side Runner technology is used to read and run test cases. The JSON file generated by Selenium Side Runner is returned to the front-end for display through a conversion interface. The displayed content includes module / function, script / use case, pass rate, person in charge, receivable, status, failure reason, and failure screenshot.

[0124] This embodiment provides a method for automated test result processing, comprising the following steps: (1) recording a test case; (2) running a test script; (3) making a real-time judgment during the running process, and taking a screenshot and storing it if the execution fails; (4) generating a test result; (5) reading, calculating, and processing the test result; and (6) displaying the processed test result on a front-end page.

[0125] The specific steps for recording test cases in step (1) are as follows: 1. Installation and startup: Install Selenium IDE in the browser's plug-in store, and find Selenium IDE in the browser's extension list to start it. 2. Create a new project: Select "Create a new project" to create a new project. Name the project and select a storage location according to actual needs. 3. Start recording: On the Selenium IDE main interface, find the red circular "Record" button and click it to start recording. At this time, Selenium IDE starts monitoring browser operations. 4. Execute operations: Perform the operation process you want to record in the browser, such as: opening a specific web page address; clicking buttons, links, and other elements on the page; entering text in the input box; selecting drop-down menu options, etc. Pay attention to the consistency and logic of the operations to ensure that the recorded test scenarios meet actual needs. 5. Set the waiting time: If the operation involves loading a page or waiting for a specific element to appear, you can manually set the waiting time. In the command list of Selenium IDE, you can find the "Wait" command and specify the waiting time by setting the time parameter. For example, "Wait 5000" means waiting for 5 seconds. 6. Stop recording: After completing the operation process, click the red circular "Stop" button on the Selenium IDE interface to stop recording. 7. View and edit the script: After recording stops, Selenium IDE will automatically generate a recorded test script and display it in the "Commands" column on the main interface. You can perform the following operations on the script: ① Check the accuracy of the commands to ensure that each operation is recorded correctly; ② Add comments to improve the readability of the script; ③ Set assertions to verify whether specific conditions are met. For example, verify whether specific text appears on the page, whether an element exists, etc.; ④ Modify command parameters to adapt to different test scenarios. 8. Test run test: In Selenium IDE, click the green triangle "Play" button to run the recorded test script; observe the test running process to check for errors or abnormalities; further adjust and optimize the test script based on the running results. 9. Save and export: After completing the editing and optimization of the test script, save the project. Selenium IDE supports exporting test scripts into multiple formats, such as code in programming languages ​​such as Java, Python, and C#, so that they can be used in different test frameworks. You can also choose to save them as the default side file.

[0126] Step (3) is judged in real time during operation. If the execution fails, the specific steps for storing the screenshot are as follows: First, use an object to store the associated information: use a common object to simulate a function similar to a hash table to store the association between the failed case and the corresponding screenshot path. The key of the object can use the unique identifier of the failed case, such as the name of the case or a unique number of the case, here is caseId. The corresponding value is the file path string of the screenshot corresponding to the failed case stored in the specified directory, such as ' / path / to / screenshots / failure_case_1.png'. In this way, the screenshot path corresponding to the specified failed case can be obtained quickly and easily through the object attribute access method (failureScreenshotObj[caseId]), which is convenient for subsequent use in operations such as generating reports. Then, an array is combined with the object to organize the data: define an array failureCases, the array elements of which are objects containing case-related information and screenshot paths. The name, description and corresponding screenshot path information of each failed case can be added to the array in the form of objects through the push method. Later, when generating reports or querying related failed use case information, you can perform corresponding operations by traversing the array. This structure makes it easier to manage and process multiple failed use cases as a whole. Finally, add screenshots and associated logic to the execution status judgment: In the source code of the Selenium Side Runner installation directory, find the execution status judgment method, and when the execution fails, call the driver.takeScreenshot() method to obtain the screenshot data (the screenshot data is returned in base64 encoding format), and write the screenshot data to a file in the specified directory. Next, directly use the use case ID as the key and the screenshot path as the value to store it in the failureScreenshotObj object to establish an association between the failed use case and the screenshot.

[0127] In addition, in steps (2) and (4), ensure that the Java Runtime Environment (JRE) or Java Development Kit (JDK) and Selenium Side Runner are installed, and execute the command "selenium-side-runner-w10.. / test / *.side --server http: / / ${corresponding test address port} / wd / hub -c "browserName=chrome goog:chromeOptions.args=[ignore-certificate-errors]" --output-directory.. / result / " in the command line. Among them, "-w ​​10" indicates the maximum number of test cases that can be run simultaneously; ".. / test / *.side" specifies the folder where the test case script files to be executed are located; the "--server" parameter specifies the address and port of the test server to ensure that the test tool can effectively communicate with the test environment; "-c"browserName=chrome goog:chromeOptions.args=[ignore-certificate-errors]"" is used to set the browser type and some specific options, which can specify the use of Chrome browser and ignore certificate errors; ".. / result / " specifies the output directory of the test results. After the test is completed, Selenium Side Runner will generate a JSON file in this directory to record the detailed results of the test. Once the JSON file of the test results is obtained, the interface written by Node.js provided in step (5) begins to work. Specifically: 1. In Node.js, it is necessary to introduce the fs module for file reading operations (the promises API can be used to facilitate asynchronous operations) and the module for processing JSON data parsing. 2. Define a function for reading and parsing files, which is used to read the JSON test result file at the specified path and extract key information from it: ① First, use await fs.readFile to read the file content at the specified path and parse it into an operable JavaScript object through JSON.parse. ② Then initialize an overallResults object to store the overall test result information, including the total number of use cases, the number of passed use cases, an array of failed use cases, and test result objects classified by module. ③ Then traverse each test case in the JSON data, count the total number of use cases, and update the number of passed use cases based on the status of the use case (assuming that there is such a field in JSON to indicate whether it passed or not). For failed use cases, extract their names, reasons for failure, and failure screenshot paths, and add them to the corresponding arrays.④ At the same time, classify and count the modules to which the use cases belong. If the module does not exist, initialize the corresponding module's test result object. Similarly, update the module's total number of use cases, the number of passed use cases, and record the failed use cases. 3. Define the calculateOverallPassRate function to calculate the overall pass rate. This function receives the overallResults object obtained from reading and parsing the file as a parameter. The details are as follows:

[0128]

[0129] This function divides the number of passed cases (passCases) by the total number of cases (totalCases), and then multiplies it by 100 to get the percentage of the pass rate. The toFixed(2) method is used to round the result to two decimal places to more standardize the pass rate value. 4. Define the function calculateModulePassRates to calculate the pass rate of each module. It is used to calculate the pass rate of each module. It is also based on the overallResults object obtained by reading the file previously. This function traverses each module in the modules attribute of the overallResults object. For each module, it determines whether its total number of cases is 0. If it is 0, the pass rate of the module is set to 0. Otherwise, the pass rate of the module is calculated by dividing the number of passed cases by the total number of cases and then multiplying it by 100 and rounding to two decimal places. The module name is used as the key and the pass rate value is stored as the value in the modulePassRates object. Finally, this object containing the pass rate of each module is returned, as follows:

[0130]

[0131] The above file reading algorithm and pass rate calculation method can efficiently extract key information from the JSON test result file output by Selenium SideRunner, and accurately calculate the overall pass rate and the pass rate of each module, thereby providing a powerful quantitative indicator for test quality assessment and facilitating subsequent analysis and decision-making by testers.

[0132] In step (6), the front-end calls this interface to render important information such as "module / function, script / use case, pass rate, person in charge, acceptable, status, failure reason, failure screenshot" into the page for display. This display method makes the test results clear at a glance, allowing team members to quickly understand the overall situation of the test. The person in charge can clearly see the test results of the module he is responsible for and take appropriate measures to fix the problem in a timely manner. The display of acceptable status allows the team to quickly determine whether the test results meet expectations. The display of failure reasons and failure screenshots provides specific clues and intuitive evidence for problem investigation and resolution.

[0133] In a specific implementation, the method for automated test result processing provided in this embodiment can be applied to a security policy management system. The detailed process is as follows:

[0134] Project Test Requirements Analysis: Communicate with the development team to understand the management system's functions, business processes, and quality objectives. Identify the system's modules and their functional capabilities, and determine which parts are suitable for automated testing. For example, frequently changing modules may not be suitable for early automated testing, while core business processes and stable functional modules are the focus of automated testing. Develop an automated testing plan, including test scope, schedule, and resource requirements.

[0135] Test environment setup: Prepare the server and operating system environment, ensuring it's as similar to the production environment as possible. Use virtual machines or container technology to quickly set up a repeatable test environment. Install Selenium IDE from your browser's plugin store. Ensure the Java Runtime Environment (JRE) or Java Development Kit (JDK) and Selenium SideRunner are installed. Run the Angular front-end page and NodeJS back-end service for automated test result processing.

[0136] Automated test case design: Design test cases based on the business processes and functional modules of the management system. For example, for the user management module, you can design test cases for user creation, modification, deletion, and query; for the permission management module, you can design test cases for operations performed by users with different permissions.

[0137] Test script recording: Use Selenium IDE to record test cases in a browser, generate the corresponding script, and save it in a designated directory. Then, perform a test run. In Selenium IDE, click the green triangle "Play" button to run the recorded test script. Observe the test run to check for errors or exceptions. Based on the results, further adjust and optimize the test script.

[0138] Test execution and monitoring: Use Selenium Side Runner to run recorded scripts and test cases from the command line, and monitor their status in real time from the command line. Screenshots are generated for failed test cases, and a JSON file is generated when the script completes.

[0139] After the test is complete, the backend interface automatically reads the automated test results in the JSON file and accurately calculates the pass rate based on the number of passed use cases. It also analyzes failures and associates the corresponding failure screenshots with the use cases. The data format required by the frontend is generated and returned to the frontend. The frontend calls this interface and generates an automated test results report based on the returned data. This report includes "module / function, script / use case, pass rate, responsible person, acceptable, status, failure reason, failure screenshots," as well as the test time period and overall pass rate. Users can conduct detailed analysis of the automated test results report, compiling statistics on the pass and failure rates of test cases and analyzing the causes and trends of failures.

[0140] In this example, a JSON file is processed through a backend interface and a detailed report is generated by the frontend, displaying rich information and making test results clear at a glance. This overcomes the lack of intuitive test results found in traditional tools. By accurately calculating the pass rate and associating it with failure screenshots, the status at the moment of failure can be directly viewed, improving the efficiency of problem location. Furthermore, due to its high versatility, this method can adapt to diverse testing needs.

[0141] Based on the method described in any of the above embodiments, the present application also provides Figure 3 A schematic diagram of the structure of an electronic device is shown in FIG. Figure 3 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile storage, and may also include other hardware required for its services. The processor reads the corresponding computer program from the non-volatile storage into the memory and then runs it to implement the method described in any of the above embodiments.

[0142] Based on the method described in any of the above embodiments, the present application also provides a computer storage medium, which stores a computer program. When the computer program is executed by a processor, it can be used to execute the method described in any of the above embodiments.

[0143] Based on the method described in any of the above embodiments, the present application further provides a computer program product comprising one or more computer programs or instructions. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. When the computer program is executed by a processor, the method described in any of the above embodiments is implemented.

[0144] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0145] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0146] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0147] The foregoing is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

[0148] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0149] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

Claims

1. A web page project testing method, characterized in that: The method comprises: Monitoring the execution status of a test script corresponding to the web page project to be tested by a Selenium tool, and obtaining first failure screenshot data of the currently executed page collected by the Selenium tool by calling a preset screenshot method when the execution status indicates that the test script is executed abnormally; When the test script is executed, the first failure screenshot data is output to the user; the first failure screenshot data is used to locate the abnormal part of the web page project to be tested.

2. The method according to claim 1, characterized in that The web page project to be tested includes multiple web page module test items; each web page module test item includes at least one function test item; The first failure screenshot data includes a plurality of data; each first failure screenshot data corresponds to the functional test item; The method further comprises: Determine a storage path for each first failure screenshot data, and store each first failure screenshot data in the corresponding storage path; For each first failure screenshot data, determining an identifier of a first functional test item corresponding to the first failure screenshot data, and storing the identifier of the first functional test item corresponding to each first failure screenshot data and a corresponding storage path in a preset screenshot array; The outputting the first failure screenshot data to the user includes: A screenshot display instruction carrying a target identifier is obtained, a target storage path is determined from the screenshot array based on the target identifier, and first failed screenshot data stored in the target storage path is output to a user.

3. The method according to claim 1, characterized in that The web page project to be tested includes multiple web page module test items; Each webpage module test item includes at least one functional test item; the method further includes: Obtaining the test result for the test script output by the Selenium tool, and deserializing the test result into a structured parsing result; Obtain a structured object to be filled; the fields of the structured object to be filled include the total number of project function test items to be filled, the number of passed project function test items to be filled, and the array of failed project function test items to be filled; Filling the total number of project functional test items to be filled in according to the total use case number field in the parsing result, filling the passed number of project functional test items to be filled in according to the status field of each functional test item in the parsing result, determining the first functional test item that failed the test according to the status field of each functional test item in the parsing result, and filling the project functional test item failure array based on a first failure screenshot data set corresponding to the first functional test item and a failure reason; wherein the first failure screenshot data set includes the first failure screenshot data; Determining a first test pass rate of the webpage item to be tested based on the total number of filled item function test items in the filled structured object and the number of passed filled item function test items; Outputting the first failure screenshot data set and the failure reason in the project function test item failure array and the first test pass rate to the user.

4. The method according to claim 3, characterized in that The fields of the structured object to be filled also include the test results of each webpage module test item to be filled; the test results of each webpage module test item to be filled include the total number of module function tests to be filled, the total number of module function test passes to be filled, and the module function test failure array to be filled; the method further includes: For each web page module test item, determine the target functional test items included in the web page module test item from the web page module test item field to which each functional test item belongs in the parsing result, fill in the total module functional test items to be filled in the web page module test item according to the number of the target functional test items, determine the total module functional test pass items and module failed functional test items to be filled in the web page module test item according to the status field of the target functional test item, and fill in the module functional test failure array to be filled based on the second failure screenshot data set of the module failed functional test item; wherein, the first failure screenshot data set includes the second failure screenshot data set; For each webpage module test item, determining a second test pass rate for each webpage module test item based on the total number of module function tests after filling and the total number of passed module function tests after filling; The second failure screenshot data set in the module function test failure array and the second test pass rate are output to the user.

5. The method according to claim 4, characterized in that The first failure screenshot data set, the failure reason, the first test pass rate, the second failure screenshot data set, and the second test pass rate are output to the user through a Node.js interface.

6. The method according to claim 1, characterized in that The method further comprises: receiving an assertion insertion instruction, wherein the assertion insertion instruction is used to instruct the Selenium tool to insert an assertion statement at a target location in the test script; the assertion statement is used to instruct to terminate execution of the test script at the target location; According to the execution status of the test script before the target position, the code statement where the exception occurs in the test script is determined.

7. The method according to any one of claims 1 to 6, characterized in that: The screenshot method includes the driver.takeScreenshot() method; the format of the first failed screenshot data includes the base64 encoding format.

8. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing processor-executable instructions; Wherein, when the processor calls the executable instruction, the method according to any one of claims 1 to 7 is implemented.

9. A computer-readable storage medium, characterized in that Computer instructions are stored thereon, and when the computer instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images