A Web project inspection method and system

Abstract

The present invention discloses a Web project inspection method and system, comprising the following steps: starting a headless browser, obtaining a Web project route, the Web project route comprising a Web project route structure and a plurality of pages, the Web project route structure comprising a path relationship between the plurality of pages; reading the Web project route, the headless browser sequentially running each page according to the Web project route structure, recording the error content and position whenever an error occurs on a page, until each page in the Web project route is run and completed, and then terminating the inspection; collecting all error contents and their corresponding positions, obtaining an error log, and returning the error log. The present invention performs a running test on all pages of a Web project according to the route structure by a headless browser, utilizes the feature that the headless browser does not need to be rendered, improves the test speed, and can exhaustively test all pages through the route structure, saving the manpower cost and time cost of project inspection.

Description

Technical Field

[0001] The present invention relates to the technical field of front-end development, and in particular to a Web project inspection method and system. Background Art

[0002] In front-end development, projects often need to be packaged. The commonly used packaging tool vite is loaded and requested on demand in the development environment, and the files are statically checked during packaging, but not at runtime. That is to say, page files that are not currently loaded will not be loaded by the packaging tool. If some changes are made to the global data, and the current debugging page does not cause any problems, it is directly packaged. It is very likely that this change affects other pages, but it has not been checked. Many times, after packaging to the test environment, testers find that some pop-up boxes / pages cannot be displayed during actual operation.

[0003] The current solution to the above problems is for developers to manually test or run all test cases, which is time-consuming and laborious. Therefore, a method that can automatically check the Web project before packaging is needed. Summary of the invention

[0004] To solve the above problems, the present invention provides a Web project inspection method and system, which uses a headless browser to perform detailed testing and inspection on Web projects according to routing, thereby solving the problem that the prior art tests Web projects in a time-consuming and labor-intensive manner.

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

[0006] A web project inspection method comprises the following steps:

[0007] S1. Start a headless browser and obtain a Web project route, wherein the Web project route includes a Web project route structure and a plurality of pages, wherein the Web project route structure includes a path relationship between the plurality of pages;

[0008] S2. Read the Web project route, and the headless browser runs each page in sequence according to the Web project route structure. Whenever an error occurs on a page, the error content and location are recorded until each page in the Web project route is run and completed, and then the check ends;

[0009] S3. Collect all error contents and their corresponding locations, obtain error logs, and return the error logs.

[0010] Furthermore, in step S1, the Web project routing structure is a directory structure or a preset routing structure of all pages.

[0011] Furthermore, in step S1, vite-plugin-pages is used to generate the directory structure of all the pages.

[0012] Further, in step S2, the headless browser runs each page in sequence according to the Web project routing structure, and its specific implementation method includes: the Web project routing structure includes a root route, and the headless browser starts from the root route and runs each page one by one according to the depth-first principle or the breadth-first principle.

[0013] Further, in step S2, whenever an error occurs on a page, the error content and location are recorded, specifically including: monitoring the headless browser console, obtaining the error information of the console, determining whether the page is wrong according to the error information of the console, and recording the error code location and error type.

[0014] Furthermore, in step S2, a preset script is also included, and the script interacts with the page on a specific page and collects the return value obtained by the interaction.

[0015] Furthermore, in step S3, the formats of the error log include: excel format, toml format, yaml format and json format.

[0016] Furthermore, after step S3, the method further includes: collecting error logs checked multiple times, and counting the pages with the most errors in the error logs.

[0017] Through the above technical solution, the present invention has the following beneficial effects:

[0018] Through the headless browser, all pages of the Web project are tested according to the routing structure. The headless browser does not require rendering to improve the testing speed. The routing structure can be used to test all pages in detail, saving the manpower and time costs of Web project inspection. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 The figure is a schematic diagram of the overall flow of a Web project inspection method of the present invention.

[0020] Figure 2 The figure is a schematic diagram of the structure of a Web project inspection system in an embodiment of the present invention. DETAILED DESCRIPTION

[0021] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0022] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] Example 1

[0024] See also Figure 1 , a Web project inspection method, comprising the following steps:

[0025] S1. Start a headless browser and obtain a Web project route, wherein the Web project route includes a Web project route structure and a plurality of pages, wherein the Web project route structure includes a path relationship between the plurality of pages;

[0026] S2. Read the Web project route, and the headless browser runs each page in sequence according to the Web project route structure. Whenever an error occurs on a page, the error content and location are recorded until each page in the Web project route is run and completed, and then the check ends;

[0027] S3. Collect all error contents and their corresponding locations, obtain error logs, and return the error logs.

[0028] Routing is a way to interact with the backend server. Requesting different resources through different paths and requesting different pages is one of the functions of routing. The role of routing is to bind the browser URL and the content seen by the user in a single-page application. When the user browses different pages in the application, the URL will be updated accordingly, but the page does not need to be reloaded from the server.

[0029] The headless browsers include Playwright, Puppetter, and Selenium. A headless browser is a web browser without a graphical user interface, and is usually controlled by programming or a command line interface. Since a headless browser does not have a graphical user interface, it does not need to load CSS and render pages during automatic testing, which can save CPU and memory, and is faster during testing.

[0030] In an optional embodiment, in step S1, the Web project routing structure is a directory structure or a preset routing structure of all pages.

[0031] The routing structure can be understood as a container, or a mechanism, that manages a set of routes. Routing is just a mapping between URLs and functions. When a URL is received, the corresponding function is searched in the routing mapping table. This process is handled according to the routing structure.

[0032] It also supports preset routes, and tests are performed according to the routes configured by the tester, which improves the flexibility of the test.

[0033] In an optional embodiment, in step S1, vite-plugin-pages is used to generate the directory structure of all the pages.

[0034] In large web projects, configuring the Web routing structure often requires a lot of manpower and resources. The vite-plugin-pages plug-in can automatically generate the routing structure based on the directory structure of the page file.

[0035] In an optional embodiment, in step S2, the headless browser runs each page in sequence according to the Web project routing structure, and its specific implementation method includes: the Web project routing structure includes a root route, and the headless browser starts from the root route and runs each page one by one according to the depth-first principle or the breadth-first principle.

[0036] The depth-first principle starts from the root route and runs all the pages of each branch until all the pages of this branch are run, and then runs the pages of other branches, and each page is run only once.

[0037] The breadth-first principle starts from the root route and runs the page closest to the root route first, until all pages are run to completion, and each page is run only once.

[0038] In an optional embodiment, in step S2, whenever a page error occurs, the error content and location are recorded, specifically including: monitoring the headless browser console, obtaining the error information of the console, determining whether the page is wrong based on the error information of the console, and recording the error code location and error type.

[0039] In an optional embodiment, in step S2, a preset script is also included, and the script interacts with the page on a specific page and collects the return value obtained by the interaction.

[0040] By writing scripts, such as clicking a button on a page and injecting the scripts, these scripts are loaded and executed on the corresponding page.

[0041] In an optional embodiment, in step S3, the formats of the error log include: excel format, toml format, yaml format and json format.

[0042] Supports error log output in multiple formats to meet the different needs of testers.

[0043] In an optional embodiment, after step S3, the method further includes: collecting error logs checked multiple times, and counting the pages with the most errors in the error logs.

[0044] After each modification, the errors will be recorded and counted, and a report will be generated to show which page is most susceptible to the changes, so that testers can know which page is susceptible to which changes.

[0045] Example 2

[0046] See also Figure 2 , a web project inspection system, comprising:

[0047] A route acquisition module, used to start a headless browser and acquire a Web project route, wherein the Web project route includes a Web project route structure and a plurality of pages, and the Web project route structure includes a path relationship between the plurality of pages;

[0048] The error checking module is used to read the Web project route. The headless browser runs each page in sequence according to the Web project route structure. Whenever an error occurs on a page, the error content and location are recorded until each page in the Web project route is run and completed, and then the check ends.

[0049] The log generation module is used to collect all error contents and their corresponding locations, obtain error logs, and return error logs.

[0050] The embodiment disclosed in this specification is only an example of a unilateral feature of the present invention, and the protection scope of the present invention is not limited to this embodiment, and any other functionally equivalent embodiments fall within the protection scope of the present invention. For those skilled in the art, various other corresponding changes and deformations can be made according to the technical solutions and concepts described above, and all of these changes and deformations should fall within the protection scope of the claims of the present invention.

Claims

1. A Web project inspection method, characterized in that: The following steps are involved: S1. Start a headless browser and obtain a Web project route, wherein the Web project route includes a Web project route structure and several pages, wherein the Web project route structure is a directory structure or a preset route structure of all pages, and the Web project route structure includes a path relationship between several pages; S2. Read the Web project route, and the headless browser runs each page in turn according to the Web project route structure, monitors the headless browser console, obtains the error information of the console, determines whether the page has an error according to the error information of the console, records the error code location and error type, and ends the inspection after each page in the Web project route has been run; S3. Collect all error contents and their corresponding locations, obtain error logs, and return the error logs.

2. A Web project inspection method according to claim 1, characterized in that: In step S1, vite-plugin-pages is used to generate the directory structure of all the pages.

3. A Web project inspection method according to claim 2, characterized in that: In step S2, the headless browser runs each page in sequence according to the Web project routing structure, and its specific implementation method includes: the Web project routing structure includes a root route, and the headless browser starts from the root route and runs each page one by one according to the depth-first principle or the breadth-first principle.

4. A Web project inspection method according to claim 1, characterized in that: In step S2, it also includes: executing a preset script, wherein the script interacts with a page on a specific page and collects a return value obtained by the interaction.

5. A Web project inspection method according to claim 1, characterized in that: In step S3, the formats of the error log include: excel format, toml format, yaml format and json format.

6. A Web project checking method according to claim 1, characterized in that: After step S3, the method further includes: collecting error logs checked multiple times, and counting the pages with the most errors in the error logs.

7. A Web project inspection system, characterized in that: include: A routing acquisition module is used to start a headless browser and acquire a Web project route, wherein the Web project route includes a Web project routing structure and a plurality of pages, wherein the Web project routing structure is a directory structure or a preset routing structure of all pages, and wherein the Web project routing structure includes a path relationship between a plurality of pages; The error checking module is used to read the Web project route. The headless browser runs each page in turn according to the Web project route structure, monitors the headless browser console, obtains the error information of the console, determines whether the page has an error according to the error information of the console, records the error code location and error type, and ends the check after each page in the Web project route has been run. The log generation module is used to collect all error contents and their corresponding locations, obtain error logs, and return error logs.

Images