Method for analyzing front-end page coverage rate based on code instrumentation

Abstract

The invention relates to the field of code instrumentation, and discloses a method for analyzing front-end page coverage rate based on code instrumentation, which is used for solving the problem that part of coverage rate data cannot be acquired when code analysis is performed through code instrumentation, and comprises the following steps: adding an instrumentation configuration plug-in in a front-end project, the method comprises the following steps: deploying a front-end project containing an instrumentation code into a test environment, executing a function test of a front-end page in the test environment, recording each executed code path, regularly reporting collected coverage rate data, receiving and processing the coverage rate data from the front end, and storing the processed data in a database. According to the method, the coverage rate report is generated and checked, test case optimization is carried out for uncovered code paths, the test is executed again, the optimized coverage rate data is reported again, and a new coverage rate report is formed through data processing and report generation, so that the accurate test range is effectively narrowed, and the difficulty in analyzing the coverage rate data is reduced.

Description

Technical Field

[0001] The present invention relates to the field of code instrumentation, and more specifically to a method for analyzing front-end page coverage based on code instrumentation. Background Art

[0002] As user demands continue to increase, the structure of web applications has become more and more complex. In the process of using some large single-page application frameworks such as react and vue, we not only take advantage of their rich interactions and dynamic loading features, but also require us to improve the adequacy of front-end testing. Faced with some complex front-end scenarios, traditional black box testing has no way to accurately evaluate the completeness of the test, especially for the coverage of asynchronous operations, event handling, conditional branches, and component life cycle functions.

[0003] Therefore, some front-end coverage tools came into being. The commonly used method is to instrument the code, dynamically track the code execution path in the actual running environment, and count whether each module and functional point has been fully tested. By quantifying the front-end code coverage, testers can accurately understand the extent of test cases covering the source code and find out the "blind spots" that are not covered by the test, so as to optimize the test strategy in a targeted manner, improve product quality, reduce potential defects and vulnerabilities, and provide important quality control indicators for continuous integration and continuous deployment.

[0004] The existing code instrumentation analysis method can only view the coverage data of the js part, but the coverage data of the html and css parts cannot be collected.

[0005] In view of the above problems, the present invention proposes a solution. Summary of the invention

[0006] In order to overcome the above-mentioned defects of the prior art, the present invention provides a method for analyzing the front-end page coverage based on code instrumentation to solve the problems existing in the above-mentioned background technology.

[0007] To achieve the above object, the present invention provides the following technical solutions:

[0008] A method for analyzing front-end page coverage based on code instrumentation includes the following steps:

[0009] Step 1: Add an instrumentation configuration plug-in to the front-end project. The plug-in will embed the monitoring code into all files during the project build process.

[0010] Step 2: Deploy the front-end project containing the instrumentation code to the test environment. The test environment should be consistent with the production environment. During the deployment process, ensure that all configurations are correct and the instrumentation plug-ins and services are running normally.

[0011] Step 3: The tester performs functional testing of the front-end page in the test environment. During the test, each executed code path is automatically recorded through the instrumentation code.

[0012] Step 4: Configure a scheduled task in the front-end project to regularly report the collected coverage data, which includes the code coverage information of each file;

[0013] Step 5: The coverage data collection service receives the coverage data from the front end and processes it, including data cleaning, aggregation and analysis operations, and stores the processed data in the database;

[0014] Step 6: Generate and view the coverage report on the coverage platform;

[0015] Step 7: Based on the coverage report, developers optimize test cases for uncovered code paths, re-execute the test, and report the optimized coverage data again. After data processing and report generation, a new coverage report is formed.

[0016] Preferably, the steps of deploying the front-end project containing the plug-in code into the test environment are:

[0017] Ensure that the test environment has been set up and its server configuration, network settings, database connection, and cache configuration are consistent with those of the production environment. The test environment needs to be stable and have sufficient resources to run the front-end project containing the instrumented code. Confirm that all dependencies in the test environment have been correctly configured and are available.

[0018] Execute project build in the development environment to compile and package the source code of the front-end project;

[0019] Transfer the generated build files to the server of the test environment, and configure the static resource path and routing of the project on the Web server of the test environment;

[0020] Configure environment variables in the test environment, including API endpoints, database connection strings, and authentication keys, and set debugging options;

[0021] After deployment is complete, check the normality of the application in the test environment and perform a quick functional verification;

[0022] Set the path and frequency for the instrumented code in the application to report coverage data, perform preliminary operations in the test environment, and check whether the coverage data can be correctly reported and received;

[0023] After the deployment is complete, notify the tester that the test environment is ready.

[0024] Preferably, the tester performs functional testing steps of the front-end page in the test environment as follows:

[0025] The tester verifies the correctness and stability of the test environment, ensures that all related services are running normally and the network connection is normal; opens the front-end page, checks the page loading speed, the correctness of resources, and whether there are any initial errors;

[0026] According to the test requirements, clarify the functional modules and pages that need to be tested, determine the core functions, user processes and edge cases that need to be tested; prepare detailed test cases that cover the operation steps, expected results, input data and boundary conditions of all functional modules;

[0027] According to the test cases, perform each functional test step by step, simulate the actual operation of users on the page, test different user operation paths; test the page behavior under abnormal conditions;

[0028] After each functional test is completed, all passed test cases and defects are recorded;

[0029] During the test, the coverage analysis tool is used to monitor whether the coverage data is reported correctly;

[0030] After the initial testing is completed, analyze the current code coverage report, identify uncovered code paths, and design and execute additional test cases for these paths;

[0031] After the developer fixes the defect, retest the relevant functional modules;

[0032] All test results are collated, including passed test cases, defects found, uncovered code paths, and any anomalies, and a test report is generated. After the test is completed, a final code coverage report is generated.

[0033] Preferably, the coverage data collection service receives coverage data from the front end and performs processing steps as follows:

[0034] Collect and parse the coverage data reported by the web end to generate the data structure required by the business. The coverage data includes the tester name, project name, branch, commitId and coverage information;

[0035] In the generated data structure, the incremental line information is calculated and marked by obtaining the branch diff information and comparing it as the incremental coverage data;

[0036] De-duplicate the incremental coverage data;

[0037] The coverage data is saved in a database.

[0038] Preferably, the step of obtaining branch diff information, comparing and calculating the incremental line information, and marking the incremental line information is as follows:

[0039] Determine two branches to be compared, that is, two versions, and use a version control system to obtain code differences between the two versions, where the code differences include newly added code lines, deleted code lines, and modified code lines;

[0040] Parse the diff information, identify the change type of each line, and extract the affected file name and specific line number from the diff information;

[0041] Get the current coverage data, compare the incremental lines in the diff information with the current coverage data, and determine which incremental lines have been covered and which have not been covered;

[0042] For the incremental lines identified in the diff, mark them;

[0043] Integrate the marked incremental line information into the overall coverage data structure, organize all processed incremental line information, and generate a complete incremental coverage data structure;

[0044] Ensure that all marked incremental row data is properly collated and recorded and saved to the database.

[0045] Preferably, the steps of generating and viewing the coverage report on the coverage platform are:

[0046] Count the number of application accesses and coverage execution times;

[0047] View coverage data for each file;

[0048] View the number of coverage files, total coverage ratio, statement, branch, line, function coverage ratio, and incremental coverage ratio information for each application's corresponding branch according to the application dimension.

[0049] Preferably, according to the coverage report, the developer performs the following steps to optimize the test cases for the uncovered code paths:

[0050] Review the generated coverage report to identify the specific locations of uncovered code;

[0051] Look deeply into uncovered code, understand its functions and expected behaviors, and analyze the reasons why these codes are not covered;

[0052] Based on the uncovered code, identify new test cases and design operation steps;

[0053] Implement newly designed test cases in the test framework, reuse existing test cases and test frameworks, and extend them to cover new code paths;

[0054] Run the newly added test cases and regenerate the coverage report after the test cases are run;

[0055] After the coverage reaches the expected level, optimize the test cases. After completing the test case optimization, check whether the code needs to be refactored.

[0056] Technical effects and advantages of the present invention:

[0057] Add an instrumentation configuration plug-in to the front-end project, deploy the front-end project containing the instrumentation code to the test environment, perform functional testing of the front-end page in the test environment, record each executed code path, regularly report the collected coverage data, receive the coverage data from the front-end, process it, store the processed data in the database, generate and view the coverage report, optimize the test cases for uncovered code paths, re-execute the test, report the optimized coverage data again, and form a new coverage report after data processing and report generation.

[0058] Narrow the scope of precise testing, improve testing efficiency, help testers improve test scenarios, and reduce missed testing issues; from the perspective of R&D personnel: improve code quality, and timely discover potential problems and vulnerabilities by viewing uncovered data, thereby reducing errors and failures in the production environment and improving code stability and reliability. Enhance code maintainability, coverage detection can help developers better understand code structure and behavior, and make code maintenance and modification easier. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 It is the overall flow chart of the present invention.

[0060] Figure 2 This is a screenshot of the coverage platform function of the present invention. DETAILED DESCRIPTION

[0061] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the present invention. In addition, the forms of the various structures recorded in the following embodiments are only examples. The method for analyzing the front-end page coverage based on code instrumentation involved in the present invention is not limited to the various structures recorded in the following embodiments. All other implementations obtained by ordinary technicians in this field without making creative work belong to the scope of protection of the present invention.

[0062] The present invention provides a method for analyzing front-end page coverage based on code instrumentation, comprising the following steps:

[0063] Step 1: Add an instrumentation configuration plug-in to the front-end project. The instrumentation configuration plug-in is used to automatically insert monitoring points in the project code to record code coverage when the code is executed. The plug-in will embed the monitoring code into all relevant files during the project build process to ensure that all key code paths are tracked;

[0064] The addition of the instrumentation configuration plug-in in the front-end project is based on the babel-plugin-istanbul plug-in to implement the instrumentation of the source code project, and the relevant configuration can be completed in the project.

[0065] Step 2: Deploy the front-end project containing the instrumentation code to the test environment. The test environment should be highly consistent with the production environment to ensure the reliability and accuracy of the test results. During the deployment process, ensure that all configurations are correct and the instrumentation plug-ins and related services are running normally.

[0066] In this embodiment, it should be specifically explained that the steps of deploying the front-end project containing the instrumentation code into the test environment are:

[0067] Make sure the test environment has been set up and is as similar to the production environment as possible, including server configuration, network settings, database connections, and cache configuration. The test environment needs to be stable and have sufficient resources to run the front-end project containing the instrumented code; confirm that all dependencies in the test environment (such as third-party libraries, API services, databases, etc.) have been correctly configured and are available. These dependencies are critical to the normal operation of the front-end project;

[0068] Execute the project build in the development environment, compile and package the source code of the front-end project. At this point, the instrumentation plug-in has taken effect in the project, ensuring that the generated build file contains the instrumentation code; the build process will generate a set of static files for deployment (such as HTML, CSS, JavaScript files, etc.). These files contain all the instrumented code and are ready to be deployed to the test environment;

[0069] Transfer the generated build files to the server of the test environment through a secure method (such as SFTP, SCP, CI / CD tools, etc.). Ensure that all files are fully transferred and the directory structure is correct; configure the static resource path and routing of the project on the Web server of the test environment. Ensure that the server can correctly provide these static files and allow testers to access the front-end pages;

[0070] Configure the required environment variables in the test environment, which usually include API endpoints, database connection strings, authentication keys, etc. Make sure that the environment variables match the running requirements of the instrumentation code to avoid runtime errors; if necessary, set debugging options or log output so that you can monitor the running of the instrumentation code during testing. This is very important for troubleshooting and verifying that the instrumentation is executed correctly;

[0071] After the deployment is complete, first check whether the application in the test environment starts normally. Access the front-end page to ensure that all resources are loaded normally without errors; perform a quick function verification to check whether key functions are running normally. This step ensures that the introduction of the instrumentation code does not affect the basic functions of the application;

[0072] Set the path and frequency for the instrumented code in the application to report coverage data, and ensure that the coverage data can be correctly sent to the server or database for collection; perform preliminary operations in the test environment to check whether the coverage data can be correctly reported and received. The data transmission status can be confirmed through logs or monitoring tools;

[0073] After the deployment is complete, inform the tester that the test environment is ready and can start testing. Provide the necessary test environment access information and debugging guidance.

[0074] Step 3: The tester performs functional testing of the front-end page in the test environment. During the test, the instrumentation code automatically records each executed code path. The test can be completed manually or with automated testing tools (such as Selenium, Puppeteer, etc.) to ensure that all possible user operation scenarios are covered;

[0075] In this embodiment, it should be specifically explained that the tester performs the following steps to perform functional testing of the front-end page in the test environment:

[0076] Before starting the test, the tester first needs to verify the correctness and stability of the test environment. Make sure that all related services (such as backend API, database, third-party services) are running normally and the network connection is normal; open the front-end page, check the page loading speed, the correctness of resources (such as CSS, JavaScript, images, etc.), and whether there are any initial errors or warnings;

[0077] According to the test requirements, clearly identify the functional modules and pages that need to be tested. Determine which core functions, user processes, edge cases, etc. need to be tested to ensure that all key code paths are executed; prepare detailed test cases that cover the operation steps, expected results, input data, and boundary conditions of all functional modules. Ensure that the test cases can fully verify the functions of the front-end page;

[0078] According to the test cases, execute each functional test step by step. Including but not limited to form submission, button clicks, page navigation, data display and update, etc. Each operation will trigger the execution of the code and record the coverage data; simulate the actual user operations on the page, including mouse clicks, keyboard input, touch gestures, etc. Test different user operation paths to ensure that all possible user interaction scenarios are covered; test page behavior in extreme or abnormal situations, such as entering invalid data, loading pages under low network bandwidth, rapid and continuous operations, etc., to verify the robustness and error handling capabilities of the system;

[0079] After each functional test is completed, verify whether the actual results are consistent with the expected results. Record all passed test cases and any possible defects or abnormal behaviors; during the test process, if any abnormal situation is encountered (such as page crashes, uncaught errors, performance bottlenecks, etc.), immediately record detailed information, including the conditions under which the abnormality occurred, log information, and screenshots;

[0080] During the test, monitor whether the coverage data is reported correctly. Verify whether the data contains all executed code paths by checking logs or using coverage analysis tools. If possible, use real-time coverage analysis tools to observe the current code coverage and ensure that the test operation triggers the expected code execution path.

[0081] After the initial testing is completed, analyze the current code coverage report to identify uncovered code paths. Design and execute additional test cases for these paths to improve coverage; repeat functional testing on different browsers and devices to ensure cross-platform compatibility of front-end pages. Test different screen sizes, operating system versions, browser engines, etc.

[0082] After developers fix any defects found during testing, retest related functional modules to ensure that the problems have been resolved and no new defects have been introduced; after completing the main test, re-test the key user paths and core functional modules to ensure that these key functions remain stable and correct after any code modifications;

[0083] Organize all test results, including passed test cases, defects found, uncovered code paths, and any anomalies. Generate test reports and provide them to relevant development teams and project managers; after the test is completed, generate a final code coverage report. Analyze coverage data, identify code sections that need further testing, and recommend possible improvement measures.

[0084] Step 4: Configure a scheduled task in the front-end project to regularly report the collected coverage data, which includes code coverage information for each file, such as function coverage, branch coverage, line coverage, etc. The reported data will be sent to the coverage collection service for further processing;

[0085] Regular reporting of coverage data can help the team understand the changes in code coverage in real time. In this way, the team can monitor which parts of the code are executed and tested at any time during the development and testing process, and promptly discover untested code areas; by automatically reporting coverage data through scheduled tasks, developers do not need to manually trigger data reporting or generate coverage reports. This automation reduces the possibility of errors in human operations and saves time, allowing developers to focus on coding and testing; regular reporting of data can ensure the continuity and integrity of coverage data and avoid data loss due to emergencies (such as system crashes or network interruptions). Regularly reported data also helps to establish a historical record of coverage, which is convenient for subsequent trend analysis; regularly reported data can be used for incremental analysis to help identify which new code or modified lines of code are covered by tests in recent changes. In this way, the team can test new code more effectively and improve overall testing efficiency; through regularly reported coverage data, team members can obtain coverage reports in a timely manner and discuss and give feedback within the team. This transparency helps improve team collaboration efficiency and promptly resolve issues with low coverage. Scheduled tasks can be reported during periods of low system load to avoid the impact of data reporting during peak hours on the performance of front-end applications, thereby optimizing resource usage and ensuring smooth system operation.

[0086] Step 5: The coverage data collection service receives coverage data from the front end and processes it. The processing process includes data cleaning, aggregation, analysis and other operations to generate accurate code coverage statistics. The processed data will be stored in the database for subsequent analysis and report generation;

[0087] The coverage data collection service is mainly used to collect the full and incremental coverage data generated during the business testing process, and generate business demand data through certain rules.

[0088] In this embodiment, it should be specifically explained that the coverage data collection service receives coverage data from the front end and performs processing steps as follows:

[0089] Collect and parse coverage data reported by the web end, generate data structures required by the business, and provide data sources for data visualization. The coverage data includes tester name, project name, branch, commitId, and coverage information. The coverage information includes file name, function coverage, statement coverage, branch coverage, and line coverage.

[0090] In the generated data structure, the incremental line information is calculated and marked by obtaining the branch diff information comparison as the incremental coverage data. The diff information refers to the data used to display the differences between two versions of code or files in the version control system. It usually includes the newly added, deleted or modified lines of code, as well as the specific location (line number) of these changes in the file. The diff information helps developers identify the specific content of the code changes, making it easier to review, merge and manage code changes;

[0091] De-duplicate the incremental coverage data to ensure data accuracy;

[0092] The incremental coverage data is deduplicated and coverage data of the same person, the same project, the same branch, and the same submission is merged. The coverage data includes the coverage of statements, branches, lines, and functions of each file. Each time the data reported by the same person, project, branch, or submission is merged, these four types of data will be merged once to prevent duplicate records from being saved.

[0093] The coverage data is saved in the database to achieve data persistence.

[0094] In this embodiment, it should be specifically explained that the steps of obtaining branch diff information, comparing and calculating the incremental line information, and marking the incremental line information are as follows:

[0095] Identify two branches or commit points to compare, usually the current development branch and the master branch (or base branch). These branches represent two different versions of the code base; use the version control system to obtain the code differences between the two versions, including the newly added lines of code, the deleted lines of code, and the modified lines of code;

[0096] Parse the diff information and identify the change type (addition, deletion, modification) of each line. This is because different types of changes may be handled differently in subsequent coverage analysis; extract the affected file names and specific line numbers from the diff information. Each affected file will have a specific line number range, indicating which lines of code are incremental;

[0097] Get the current coverage data, which usually includes the coverage of each file (such as line coverage, branch coverage, etc.); compare the incremental lines in the diff information with the current coverage data to determine which incremental lines have been covered and which have not been covered, which can help identify blind areas of test coverage;

[0098] For the incremental lines identified in the diff, special marks are added (such as "incremental" or "new code"). These marks will help with subsequent analysis, especially in coverage reports, where the coverage of incremental code is usually the focus of attention; further subdivide the code lines marked as incremental, indicating which incremental lines have been covered by tests and which are still not covered. This allows you to intuitively understand whether the newly added or modified code has been fully tested;

[0099] Integrate the marked incremental line information into the overall coverage data structure, making the incremental line part of the coverage analysis; organize all processed incremental line information to generate a complete incremental coverage data structure. This data structure can be further used to generate incremental coverage reports to help development teams focus on testing newly changed code;

[0100] Ensure that all marked incremental row data is properly collated and recorded, ready to be saved to a database or other persistent storage for subsequent analysis and report generation.

[0101] Step 6: Generate and view coverage reports on the coverage platform. The reports will visually display the code coverage of each module and file in the test, helping developers identify uncovered code paths, optimize test cases, and improve the code quality and reliability of the project;

[0102] In this embodiment, it should be specifically explained that the steps of generating and viewing the coverage report on the coverage platform are:

[0103] View the coverage aggregation statistics report. It mainly counts the number of application accesses and the number of coverage executions;

[0104] View coverage metadata. Mainly view the specific coverage data of each file;

[0105] View the coverage report. Mainly view the number of coverage files, total coverage ratio, statement, branch, line, function coverage ratio, incremental coverage ratio and other key information of each application's corresponding branch according to the application dimension.

[0106] Step 7: Based on the coverage report, developers optimize test cases for uncovered code paths and re-execute the test. The optimized coverage data will be reported again, and after data processing and report generation, a new coverage report will be formed, thus forming a closed-loop process of continuous optimization.

[0107] In this embodiment, it should be specifically explained that, according to the coverage report, the developer performs the following steps to optimize the test cases for the uncovered code paths:

[0108] Developers comprehensively review the generated coverage report and focus on those code paths that are shown as uncovered. The coverage report will show coverage by file, function, statement, and branch. Determine the specific location of uncovered code, including which files, functions, or logical branches are not covered by the test. Prioritize core business logic or high-risk code areas, as test coverage of these parts is critical.

[0109] Take a deep look at the uncovered code to understand its functions and expected behaviors. Understand the logic and context of the code and clarify why the current test cases do not cover these paths; analyze the reasons why the code is not covered. For example, it may be due to conditional branches, exception handling paths, specific input data not being triggered, etc.

[0110] Based on the understanding of uncovered code, clarify the specific goals of the new test cases, that is, which functions, logical paths or edge conditions need to be covered by the new test cases; design appropriate input data or operation steps to ensure that the uncovered code paths can be triggered when executing the test. Especially in complex logic such as conditional branches and exception handling, the design of input data needs to be particularly cautious;

[0111] Implement newly designed test cases in the test framework to ensure that they can be executed correctly and verify the expected behavior of uncovered code. Test cases should be as independent as possible, easy to execute and debug; reuse existing test cases or test frameworks, extend them to cover new code paths, reduce duplication of work and improve testing efficiency;

[0112] Run the newly added test cases to ensure that they can correctly trigger and execute the uncovered code paths. Observe the test results to confirm that the code paths are effectively covered; after the test cases are run, regenerate the coverage report to evaluate whether the newly added test cases successfully cover the previously uncovered code. Check the coverage improvement and ensure that the newly added code paths are marked as covered;

[0113] Verify the results of all newly added test cases to ensure that they not only trigger code execution, but also verify the correct business logic and expected output. Ensure that the test cases do not generate false positives or false negatives;

[0114] After the coverage reaches the expected level, consider optimizing the test cases to improve their execution efficiency, reduce redundancy, and simplify complexity. Ensure that the test cases remain clear and maintainable; after completing the test case optimization, check whether the code needs to be refactored to improve testability or simplify logic. Refactor the code to improve code quality and maintainability while ensuring that the coverage does not decrease.

[0115] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

[0116] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for analyzing front-end page coverage based on code instrumentation, characterized in that: The following steps are involved: Step 1: Add an instrumentation configuration plug-in to the front-end project. The plug-in will embed the monitoring code into all files during the project build process. Step 2: Deploy the front-end project containing the instrumentation code to the test environment. The test environment should be consistent with the production environment. During the deployment process, ensure that all configurations are correct and the instrumentation plug-ins and services are running normally. Step 3: The tester performs functional testing of the front-end page in the test environment. During the test, each executed code path is automatically recorded through the instrumentation code. Step 4: Configure a scheduled task in the front-end project to regularly report the collected coverage data, which includes the code coverage information of each file; Step 5: The coverage data collection service receives the coverage data from the front end and processes it, including data cleaning, aggregation and analysis operations, and stores the processed data in the database; Step 6: Generate and view the coverage report on the coverage platform; Step 7: Based on the coverage report, developers optimize test cases for uncovered code paths, re-execute the test, and report the optimized coverage data again. After data processing and report generation, a new coverage report is formed.

2. According to claim 1, a method for analyzing front-end page coverage based on code instrumentation is characterized in that: The steps for deploying the front-end project containing the instrumentation code to the test environment are as follows: Ensure that the test environment has been set up and its server configuration, network settings, database connection, and cache configuration are consistent with those of the production environment. The test environment needs to be stable and have sufficient resources to run the front-end project containing the instrumented code. Confirm that all dependencies in the test environment have been correctly configured and are available. Execute project build in the development environment to compile and package the source code of the front-end project; Transfer the generated build files to the server of the test environment, and configure the static resource path and routing of the project on the Web server of the test environment; Configure environment variables in the test environment, including API endpoints, database connection strings, and authentication keys, and set debugging options; After deployment is complete, check the normality of the application in the test environment and perform a quick functional verification; Set the path and frequency for the instrumented code in the application to report coverage data, perform preliminary operations in the test environment, and check whether the coverage data can be correctly reported and received; After the deployment is complete, notify the tester that the test environment is ready.

3. The method for analyzing front-end page coverage based on code instrumentation according to claim 1, characterized in that: The tester performs functional testing steps for the front-end page in the test environment as follows: Testers verify the correctness and stability of the test environment, ensuring that all related services are running normally and the network connection is normal; Open the front-end page and check the page loading speed, resource correctness, and whether there are any initial errors; According to the test requirements, clarify the functional modules and pages that need to be tested, determine the core functions, user processes and edge cases that need to be tested; prepare detailed test cases that cover the operation steps, expected results, input data and boundary conditions of all functional modules; According to the test cases, execute each functional test step by step, simulate the actual operation of users on the page, and test different user operation paths; Test page behavior under unusual circumstances; After each functional test is completed, all passed test cases and defects are recorded; During the test, the coverage analysis tool is used to monitor whether the coverage data is reported correctly; After the initial testing is completed, analyze the current code coverage report, identify uncovered code paths, and design and execute additional test cases for these paths; After the developer fixes the defect, retest the relevant functional modules; All test results are collated, including passed test cases, defects found, uncovered code paths, and any anomalies, and a test report is generated. After the test is completed, a final code coverage report is generated.

4. The method for analyzing front-end page coverage based on code instrumentation according to claim 1, characterized in that: The coverage data collection service receives coverage data from the front end and performs the following processing steps: Collect and parse the coverage data reported by the web end to generate the data structure required by the business. The coverage data includes the tester name, project name, branch, commitId and coverage information; In the generated data structure, the incremental line information is calculated and marked by obtaining the branch diff information and comparing it as the incremental coverage data; De-duplicate the incremental coverage data; The coverage data is saved in a database.

5. The method for analyzing front-end page coverage based on code instrumentation according to claim 4, characterized in that: The steps of obtaining branch diff information, comparing and calculating incremental line information, and marking are as follows: Determine two branches to be compared, that is, two versions, and use a version control system to obtain code differences between the two versions, where the code differences include newly added code lines, deleted code lines, and modified code lines; Parse the diff information, identify the change type of each line, and extract the affected file name and specific line number from the diff information; Get the current coverage data, compare the incremental lines in the diff information with the current coverage data, and determine which incremental lines have been covered and which have not been covered; For the incremental lines identified in the diff, mark them; Integrate the marked incremental line information into the overall coverage data structure, organize all processed incremental line information, and generate a complete incremental coverage data structure; Ensure that all marked incremental row data is properly collated and recorded and saved to the database.

6. The method for analyzing front-end page coverage based on code instrumentation according to claim 1, characterized in that: The steps for generating and viewing the coverage report on the coverage platform are as follows: Count the number of application accesses and coverage execution times; View coverage data for each file; View the number of coverage files, total coverage ratio, statement, branch, line, function coverage ratio, and incremental coverage ratio information for each application's corresponding branch according to the application dimension.

7. The method for analyzing front-end page coverage based on code instrumentation according to claim 1, characterized in that: According to the coverage report, the developer performs the following steps to optimize the test cases for uncovered code paths: Review the generated coverage report to identify the specific locations of uncovered code; Look deeply into uncovered code, understand its functions and expected behaviors, and analyze the reasons why these codes are not covered; Based on the uncovered code, identify new test cases and design operation steps; Implement newly designed test cases in the test framework, reuse existing test cases and test frameworks, and extend them to cover new code paths; Run the newly added test cases and regenerate the coverage report after the test cases are run; After the coverage reaches the expected level, optimize the test cases. After completing the test case optimization, check whether the code needs to be refactored.

Images