A web application testing method and device, electronic equipment and storage medium

Abstract

This invention relates to the field of computer technology and provides a web application testing method, apparatus, electronic device, and storage medium. The web application testing method includes: locating target elements of the application under test based on a set selector; the application under test being a web application; generating at least one page element module based on the target elements; each page element module representing a set of target elements corresponding to a test page of the application under test; generating at least two test cases for the corresponding test page based on the attribute values ​​of the target elements in the page element module; organizing at least two test cases to generate at least one test script file corresponding to each test page; and executing at least one test script file to test the application under test.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a web application testing method, apparatus, electronic device, and storage medium. Background Technology

[0002] When generating test scripts, related technologies typically employ a scripting approach that integrates test data and specific business logic. This method results in significant modification work when the test scenario changes. Furthermore, relocating target elements introduces code redundancy, making later maintenance inconvenient. Summary of the Invention

[0003] To address the aforementioned problems, embodiments of the present invention provide a web application testing method, apparatus, electronic device, and storage medium, thereby at least resolving the issue of low testing efficiency in related technologies.

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

[0005] In a first aspect, embodiments of the present invention provide a web application testing method, the method comprising:

[0006] The target element of the application under test is located based on a set selector; the application under test is a web application.

[0007] At least one page element module is generated based on the target element; each page element module represents a set of target elements corresponding to a test page of the application to be tested;

[0008] Based on the attribute values ​​of the target element in the page element module, generate at least two test cases for the corresponding test page.

[0009] Organize the at least two test cases and generate at least one test script file corresponding to each test page;

[0010] Execute the at least one test script file to test the application to be tested.

[0011] In the above scheme, generating at least two test cases for the corresponding test page based on the attribute values ​​of the target elements in the page element module includes:

[0012] The driving data for each of the at least two test cases is determined based on a data-driven approach.

[0013] Based on the attribute values ​​of the target elements in the page element module, the driving data, and the business logic of each functional module of the test page, at least two test cases are generated corresponding to each functional module of the test page; the test page includes at least one functional module.

[0014] Correspondingly, the organization of the at least two test cases generates at least one test script file corresponding to each test page, including:

[0015] Deploy at least two test cases corresponding to the same functional module in the same test script file, where each test case in the test script file corresponds to a test scenario.

[0016] In the above scheme, generating at least one test script file corresponding to each test page includes:

[0017] Set the assertion timeout in the test script file corresponding to the test case whose execution result is asynchronous.

[0018] In the above scheme, the organization of the at least two test cases includes:

[0019] Based on the Hook function, set the pre-execution operation and / or post-execution operation for each test case.

[0020] In the above scheme, the step of setting the pre-execution operations and / or post-execution operations for each test case based on Hook functions includes:

[0021] If the execution of the first test case depends on the execution result of the second test case, then the dependency condition of the first test case is set based on the Hook function; the dependency condition represents the execution result of the second test case; the at least two test cases include: the first test case and the second test case.

[0022] In the above scheme, before locating the target element of the application under test based on the set selector, the method further includes:

[0023] The setting selector is determined based on the technology stack of the application under test; the setting selector corresponds to the technology stack of the application under test.

[0024] In the above scheme, after generating at least one test script file corresponding to each test page, the method further includes:

[0025] Configure the first parameter of the configuration file corresponding to the application to be tested; the first parameter represents the path of the test script file corresponding to each page element module.

[0026] Correspondingly, executing the at least one test script file to test the application under test includes:

[0027] Get the first parameter from the configuration file of the application to be tested;

[0028] Execute at least one test script file based on the first parameter.

[0029] Secondly, embodiments of the present invention provide a web application testing device, the device comprising:

[0030] The positioning module is used to locate the target element of the application under test based on a set selector; the application under test is a web application.

[0031] The first generation module is used to generate at least one page element module based on the target element; each page element module represents a set of target elements corresponding to a test page of the application to be tested;

[0032] The second generation module is used to generate at least two test cases for the corresponding test page based on the attribute values ​​of the target element in the page element module.

[0033] The third generation module is used to organize the at least two test cases and generate at least one test script file corresponding to each test page.

[0034] An execution module is used to execute the at least one test script file to test the application to be tested.

[0035] Thirdly, embodiments of the present invention provide an electronic device including a processor and a memory interconnected thereto, wherein the memory is used to store a computer program, the computer program including program instructions, and the processor is configured to invoke the program instructions to execute the steps of the Web application testing method provided in the first aspect of the present invention.

[0036] Fourthly, embodiments of the present invention provide a computer-readable storage medium, comprising: the computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of the Web application testing method provided in the first aspect of the present invention.

[0037] This embodiment locates the target elements of the application under test based on a selector, and generates at least one page element module based on the target elements. Each page element module represents a set of target elements corresponding to a test page of the application under test. Based on the attribute values ​​of the target elements in the page element modules, at least two test cases are generated for the corresponding test pages. The at least two test cases are organized to generate at least one test script file corresponding to each test page. At least one test script file is executed to test the application under test. Compared with related technologies that integrate data and specific business logic into script writing, this embodiment organizes target elements in the form of page element modules, merging the target elements involved in the test page into the same page element module, thus achieving separation of test data and business logic. Since the page element module only contains target elements and does not contain specific test data and business logic, when the page design changes, we only need to maintain the target elements in the page element module. For scenarios with changes in web design or content, only the data script needs to be maintained, which reduces code redundancy caused by locating target elements and facilitates later maintenance. Attached Figure Description

[0038] Figure 1 This is a schematic diagram illustrating the implementation process of a Web application testing method provided in an embodiment of the present invention;

[0039] Figure 2 This is a schematic diagram of a web application testing process provided in an embodiment of the present invention;

[0040] Figure 3 This is a schematic diagram of a script file generation process provided in an embodiment of the present invention;

[0041] Figure 4 This is a schematic diagram of a web application automation device provided in an embodiment of the present invention;

[0042] Figure 5 This is a schematic diagram of a web application testing device provided in an embodiment of the present invention;

[0043] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0045] A web application is an application that can be accessed via the web. The biggest advantage of web applications is their ease of access for users; all they need is a browser, without the need to install any other software. In the field of web applications, as product features become increasingly rich and version iterations become faster, testing web applications is necessary to improve product reliability.

[0046] The relevant technology is based on Selenium for automated testing of web applications. Selenium is a tool for testing web applications. Selenium's technical principle is to establish communication with the browser. The test script sends HTTP requests to the browser driver via the WebDriver API. After receiving the HTTP request, the browser driver converts it into corresponding operation instructions based on the built-in HTTPserver, and then manipulates the browser according to these instructions. The browser then returns the corresponding operation results to the browser driver. This testing method requires the browser to have WebDriver installed, and different browser engines require different WebDrivers. When testing multiple browsers simultaneously, multi-threading or multiple containers need to be started; otherwise, parallel execution across multiple browsers is not possible. Because different WebDrivers need to be installed in different browsers, and the test script and the application under test need to go through cumbersome interaction processes such as domain name resolution and three-way handshakes, the testing efficiency is low.

[0047] Secondly, when generating test scripts, related technologies typically employ a scripting approach that integrates test data and specific business logic. This method results in significant modification work when the test scenario changes. Furthermore, relocating target elements introduces code redundancy, making later maintenance inconvenient.

[0048] To address the shortcomings of the aforementioned related technologies, embodiments of the present invention provide a web application testing method that can improve testing efficiency. To illustrate the technical solution described in this invention, specific embodiments are provided below.

[0049] Figure 1 This is a schematic diagram illustrating the implementation flow of a web application testing method provided in an embodiment of the present invention. The execution subject of the web application testing method is an electronic device, including desktop computers, laptops, and servers. In practical applications, this web application testing method can be applied in a browser; test commands can be executed directly on the electronic device terminal to open the browser and execute the testing steps of this embodiment.

[0050] refer to Figure 1 Web application testing methods include:

[0051] S101, locate the target element of the application to be tested based on the set selector; the application to be tested is a web application.

[0052] Here, the application to be tested is a web application, which users can access through a browser.

[0053] Selectors are used to locate the location of the code in a target element. For example, if the target element is a login box for entering account information, the selector can locate the location of the login box's code in the HTML file. There are many types of selectors; for example, in Cascading Style Sheets (CSS), the target selector is ":target".

[0054] In one embodiment, before locating the target element of the application to be tested based on a set selector, the method further includes:

[0055] The setting selector is determined based on the technology stack of the application under test; the setting selector corresponds to the technology stack of the application under test.

[0056] This embodiment determines the target element of the application under test based on the technology stack used by the application. For example, if the webpage is developed using native JS, the target element can be located based on CSS selectors or JS code in the test script file; for webpages using front-end frameworks like React or Vue, the target element can be located based on framework-specific entity selectors, such as using React's component tree or Aurelia's element bindings. For information that is not easily obtained through the selector mechanism, such as anchor points in the current webpage address, window scroll position, view width, offset, hostname, etc., this embodiment uses the ClientFunction API to obtain the environment information of the application under test because the test script file and the application under test run in the same environment. This method makes the acquisition of target elements no longer limited to selectors, making the test script content more flexible.

[0057] S102, generate at least one page element module based on the target element; each page element module represents a set of target elements corresponding to a test page of the application to be tested.

[0058] This embodiment organizes the target elements of the application under test into page element modules. All target elements involved in a test page are grouped into a single set, called a page element module. The application under test may include multiple test pages, each corresponding to a page element module, and each page element module stores the target elements involved in that test page.

[0059] The purpose of this approach is to separate data from business logic. In this embodiment, target elements are organized in the form of page element modules. Each page element module contains only the target elements and does not include specific test data or business logic. When the page design changes, we only need to maintain the target elements in the page element modules. For scenarios involving changes in web design or content, only the data script needs to be maintained, which reduces code redundancy in locating target elements and facilitates later maintenance.

[0060] S103, Based on the attribute values ​​of the target element in the page element module, generate at least two test cases for the corresponding test page.

[0061] The page element module only stores the attribute values ​​of the target element, and does not contain specific test data or business logic. Attribute values ​​include: the target element's type, name, size, appearance, font style, etc.

[0062] Based on the testing requirements, the target element is configured according to its attribute values. This includes setting events for the target element, populating driving data, and setting assertions to generate test cases. For example, if the target element is a login box, driving data is configured based on the login box's attribute values, such as "username 123456, password 111111". The driving data can be a JSON file generated according to type rules, covering all test scenarios.

[0063] Here, the number of test cases generated is determined by the testing requirements. Multiple test cases can be generated for a single function on the test page. One test page can correspond to multiple test cases, which belong to one or more test script files. Each test script file can test one function on the test page, such as the login function of the login box.

[0064] In one embodiment, generating at least two test cases for the corresponding test page based on the attribute values ​​of the target element in the page element module includes:

[0065] The driving data for each of the at least two test cases is determined based on a data-driven approach.

[0066] Based on the attribute values ​​of the target elements in the page element module, the driving data, and the business logic of each functional module of the test page, at least two test cases are generated corresponding to each functional module of the test page; the test page includes at least one functional module.

[0067] Correspondingly, the organization of the at least two test cases generates at least one test script file corresponding to each test page, including:

[0068] Deploy at least two test cases corresponding to the same functional module in the same test script file, where each test case in the test script file corresponds to a test scenario.

[0069] This embodiment constructs driving data using a data-driven model, writes test cases with the same test scenario but different driving data, and realizes the need for one test script file to cover multiple test scenarios. One test script file is executed using different driving data, and the driving data and test behavior are completely separated. This test script design pattern is called data-driven.

[0070] A test page includes at least one functional module. For example, a test page may include a login module and a logout module. Each functional module can be functionally tested using a test script file.

[0071] In this embodiment, one driving data corresponds to one test case, and the test script file includes multiple test cases. Each test case in the test script file corresponds to a test scenario. For example, in the login function module, the business logic of the login function is the same for different users; the difference lies in the input user identity information. The user identity can be an administrator, a regular user, or a member user, and each type of user identity corresponds to a test scenario. The login function can be tested using a single test script file, which can include multiple test cases, each corresponding to a type of user identity. When the test script file is executed, it can perform login tests for multiple types of user identities with a single test script file.

[0072] In practical applications, as much driver data as possible can be constructed through mocking in order to cover more use cases.

[0073] This embodiment uses a data-driven approach to design test cases. A single test logic can be reused across multiple driving data sets, resulting in high code reusability and avoiding repetitive code writing. Data and test script files are separated, ensuring that the failure of one test case does not affect other test cases, thus improving the efficiency of anomaly troubleshooting.

[0074] S104, organize the at least two test cases and generate at least one test script file corresponding to each test page.

[0075] A test case is a specific set of input data, operations, various environmental settings, and expected results provided to the application under test for the purpose of conducting tests. A test script file consists of several test cases. By using the test cases corresponding to a page element module, the test script file corresponding to that page element module can be generated.

[0076] A test page can correspond to multiple test script files, and each test script file can correspond to multiple test cases. Test cases belonging to the same test script file from at least two test cases are grouped together to obtain a single test script file. For example, for a specific functional module on a test page, that functional module corresponds to a test script file, and that function can be tested by multiple test cases within that test script file.

[0077] In one embodiment, generating at least one test script file corresponding to each test page includes:

[0078] Set the assertion timeout in the test script file corresponding to the test case whose execution result is asynchronous.

[0079] An assertion is a first-order logic statement in a program (such as a logical judgment that results in true or false). Its purpose is to represent and verify the results expected by the software developer. When the program executes to the point of the assertion, the corresponding assertion should be true. If the assertion is not true, the program will stop execution and give an error message.

[0080] In synchronous functional testing, assertions can be executed immediately after the test operation. However, some functional tests on the web are asynchronous, meaning that the expected results cannot be obtained immediately after user interaction.

[0081] For example, after a page reaches its final state, the page being tested may need some time to send requests to the server to obtain the necessary data, or for the user to perform an action to trigger an animation. All these intervals cannot be pre-calculated because they depend on various factors such as computer performance and network connection speed.

[0082] In this scenario, executing the assertion immediately after the test operation will result in an uncertain, or at least unstable, result. Therefore, to make asynchronous functional tests more stable, it is necessary to add an assertion timeout.

[0083] In this embodiment, an assertion timeout is configured in the test script file. If an asynchronous execution result is obtained when the test case is executed, the asynchronous execution result is verified within the assertion timeout period.

[0084] Validation includes comparing the actual results with the expected results using assertion methods, such as whether they match the expected type, whether they contain a certain DOM node, and whether the number of nodes is the same.

[0085] The asynchronous execution result is verified within the assertion timeout period. If the assertion fails, the test does not fail immediately. Afterward, the assertion is retried multiple times. If the assertion cannot be verified successfully within the timeout period, the test fails.

[0086] By increasing the assertion timeout, the impact of network and environmental factors on the test results is reduced.

[0087] In one embodiment, the organization of the at least two test cases includes:

[0088] Based on the Hook function, set the pre-execution operation and / or post-execution operation for each test case.

[0089] This embodiment sets the execution environment of test cases through API hooks, including setting pre-execution and / or post-execution operations for each test case, as well as setting the initialization state after each test case is executed. For example, if the pre-execution operation of a test case is clicking the login button, this click operation can be set through a hook function, and the click operation will be automatically triggered when the test case is executed.

[0090] In one embodiment, setting the pre-execution operations and / or post-execution operations for each test case based on the Hook function includes:

[0091] If the execution of the first test case depends on the execution result of the second test case, then the dependency condition of the first test case is set based on the Hook function; the dependency condition represents the execution result of the second test case; the at least two test cases include: the first test case and the second test case.

[0092] Here, the first and second test cases are nested, meaning the execution of the first test case depends on the result of the second test case. In other words, to execute the first test case, the second test case must be executed first to obtain a result before the first test case can be executed. This prevents independent testing of the test cases; multiple related test cases must all be executed, impacting testing efficiency. Furthermore, it hinders test case maintenance; maintaining one test case also requires maintaining other related test cases.

[0093] This embodiment sets the execution environment of the first test case using a hook function, such as setting the initial page URL, the initialization state after execution, and pre-execution or post-execution operations. The execution of the first test case depends on the execution result of the second test case. Therefore, the execution result of the second test case is set using a hook function. When the first test case is executed, the execution result of the second test case is obtained through the hook function, without the second test case actually being executed.

[0094] This allows each test case to be "modularized," with logical isolation between test cases. Each test case can be tested independently without depending on other test cases, improving testing efficiency. Furthermore, when maintaining test cases, only the current test case needs to be maintained, eliminating the need to maintain multiple test cases simultaneously, thus simplifying test case maintenance.

[0095] In practical applications, Hooks can also be used to specify the user role for the current test in route interception using a user role mechanism, enabling arbitrary switching of user roles and meeting the testing requirements for users with different permissions.

[0096] After each test script file finishes execution, the state specified by the test case will be initialized. The common logic of multiple test cases can be specified through hook functions, such as specifying the starting page of all test cases in the test group.

[0097] S105, Execute the at least one test script file to test the application to be tested.

[0098] By following the steps above, at least one test script file can be obtained for each test page. By executing one or more of these test script files, the functionality of the application to be tested can be evaluated.

[0099] When executing a test script file to test the application under test, the target element corresponding to the test script file is first determined through the page element module, then the target element is located by setting a locator, and finally the target element is tested according to the driving data in the test case.

[0100] This embodiment locates the target elements of the application under test based on a selector, and generates at least one page element module based on the target elements. Each page element module represents a set of target elements corresponding to a test page of the application under test. Based on the attribute values ​​of the target elements in the page element modules, at least two test cases are generated for the corresponding test pages. The at least two test cases are organized to generate at least one test script file corresponding to each test page. At least one test script file is executed to test the application under test. Compared with related technologies that integrate data and specific business logic into script writing, this embodiment organizes target elements in the form of page element modules, merging the target elements involved in the test page into the same page element module, thus achieving separation of test data and business logic. Since the page element module only contains target elements and does not contain specific test data and business logic, when the page design changes, we only need to maintain the target elements in the page element module. For scenarios with changes in web design or content, only the data script needs to be maintained, which reduces code redundancy caused by locating target elements and facilitates later maintenance.

[0101] In one embodiment, after generating at least one test script file corresponding to each test page, the method further includes:

[0102] Configure the first parameter of the configuration file corresponding to the application to be tested; the first parameter represents the path of the test script file corresponding to each page element module.

[0103] Correspondingly, executing the at least one test script file to test the application under test includes:

[0104] Get the first parameter from the configuration file of the application to be tested;

[0105] Execute at least one test script file based on the first parameter.

[0106] Here, each application under test corresponds to a configuration file, which can be loaded in different browsers, avoiding the need to write configuration files for browsers with different engines. The configuration file contains the test script files that the application under test needs to execute. In practical applications, the configuration file can also configure information such as: browsers for concurrent execution, error screenshot save path, test report format, isolation mode, smart wait time, assertion timeout time, and page load timeout time.

[0107] In practical applications, configuration files can be in JS (JavaScript) format. Different browsers can directly load JS-formatted configuration files and obtain the information contained within them.

[0108] In this embodiment, both the application to be tested and the test script file are in a format that the browser can run directly. For example, the application to be tested corresponds to a Hyper Text Markup Language (HTML) file, and the test script file is in JS format. In this way, the application to be tested and the test script file can run in the browser at the same time.

[0109] In one embodiment, the first parameter in the configuration file refers to the src attribute of the script tag. The script tag is used to define client-side scripts, such as JavaScript. The src attribute specifies the Uniform Resource Locator (URL) for external script files, and almost all major browsers support the src attribute. In this embodiment of the invention, the src attribute points to the URL address of at least one test script file corresponding to the application under test.

[0110] For example, an example of a first parameter is: <script src="demo_script.js">< / script> .

[0111] Traditional technologies require specifying the relative path of test script files via command line when executing test cases. If multiple test script files need to be executed, numerous test script file paths must be entered into the command line, which is cumbersome and prone to errors due to manual input. This embodiment specifies the test script file paths in the src attribute of the configuration file, avoiding the need to enter numerous test script paths into the command line, thus improving testing efficiency.

[0112] Based on the first parameter in the HTML file corresponding to the application under test, the at least one test script file is executed to test the application under test; the first parameter in the HTML file points to the address of the at least one test script file.

[0113] In this embodiment, both the configuration file and the HTML file contain a first parameter. The first parameter in the configuration file tells the tester which test script files are available for the application under test, while the first parameter in the HTML file is used to execute the specific test script file. By obtaining the first parameter in the configuration file, the address of the test script file corresponding to the application under test can be obtained. Then, based on the first parameter in the HTML file corresponding to the application under test, these test script files can be executed, thereby achieving automated testing of the application under test.

[0114] In practical applications, the first parameter in an HTML file can refer to the `src` attribute of the `<script>` tag. By executing the test script file pointed to by the `src` attribute of the `<script>` tag in the HTML file, both the test script file and the application under test can be executed in the browser. Since the `src` attribute is an attribute of the `<script>` tag in the HTML file, it is not restricted by domain name and does not have cross-domain issues. Therefore, the test script file and the application under test can interact within the browser. This allows the test script file to reach the application under test without going through cumbersome interaction processes such as domain name resolution and three-way handshakes, thus achieving efficient testing.

[0115] If test script files need to be executed in parallel across multiple browsers, since both the test script files and the application under test are executed in the browsers, the browsers do not need to install WebDriver, thus saving testing time and improving testing efficiency.

[0116] In this embodiment, the configuration file can be loaded in multiple browsers, eliminating the need to write configuration files for different browsers. This embodiment improves the compatibility of page testing, achieving successful compatibility with the vast majority of browsers, including all browsers that support JavaScript, thus offering higher compatibility compared to existing technologies.

[0117] This application obtains the path to the test script files corresponding to the application under test by retrieving the first parameter in the configuration file, and then executes these test script files to test the application. This application enables interaction between the test script files and the application under test within the browser. The test script files do not need to go through cumbersome interaction processes such as domain name resolution and three-way handshakes to reach the application under test, thus achieving efficient testing. Furthermore, since both the test script files and the application under test are executed in the browser, the browser does not need to install WebDriver, saving testing time and improving testing efficiency.

[0118] In one embodiment, executing the test script files corresponding to each page element module to test the application under test includes:

[0119] The verification code data of the application under test is obtained based on the set verification code recognition library;

[0120] Based on the obtained verification code data and user information, an automated login test is performed on the application under test.

[0121] In automated login testing, some scenarios (such as login pages protected against brute-force attacks) require CAPTCHA verification. Currently, common web application testing methods bypass user authentication by setting cookies in the request header. This means that login page testing still requires manual intervention, necessitating the manual input of CAPTCHAs, leading to low testing efficiency.

[0122] Here, the CAPTCHA recognition library can be an Optical Character Recognition (OCR) library. For the scenario of automatic user login that requires CAPTCHA, this embodiment calls an OCR library based on feature extraction methods to read random CAPTCHA data created by canvas, which includes at least bitmap and grayscale information. The CAPTCHA data and user information are submitted to the server through form data. The server compares the received CAPTCHA with the Session stored in the backend to determine whether to allow the user to log in to the system homepage. This solves the problem that existing technologies cannot achieve automated testing scenarios when using login pages that are protected against brute-force attacks.

[0123] In one embodiment, the test script file also supports a timeout waiting mechanism, and the timeout waiting duration of the selector can be set in the configuration file.

[0124] Due to resource constraints or network latency, the selector may not be able to find the target element, resulting in a test failure report. A delay mechanism is needed to match the script's execution speed with the program's response speed; the timeout mechanism addresses this issue. By increasing the timeout duration when retrieving the target element, test stability is improved.

[0125] In one embodiment, the configuration file includes a test report format; after executing the at least one test script file to test the application under test, the method further includes:

[0126] A test report is generated based on the test report format configured in the configuration file.

[0127] For the test results of the test script file, the format and storage path of the test report can be configured in the configuration file. The test results can be sent to the browser driver in HTML or reporter format, and the final test report is saved in the storage path set in the configuration file.

[0128] After the test script file finishes executing, clear cookies and test data stored in the local cache to avoid affecting subsequent test operations.

[0129] refer to Figure 2 , Figure 2This is a schematic diagram of a web application testing process provided by an embodiment of the present invention. The web application testing process includes:

[0130] The first step is to configure the test script file to be run in the configuration file.

[0131] Specifically, you can specify the test script file to be executed by configuring the src attribute in the configuration file. You can also configure the browsers attribute to specify the browsers that need to be executed in parallel; configure the screenshots attribute to configure automatic screenshots of errors and their storage paths; and configure the target element search timeout, validation timeout, and page load timeout respectively through the selectorTimeout, assertionTimeout, and pageLoadTimeout attributes.

[0132] The second step is to determine the selector to locate the target element based on the technology stack of the web application.

[0133] For web pages developed using native JavaScript, the target element is located based on CSS selectors or client-side JavaScript code; for web pages using front-end frameworks such as React or Vue, the target element is located based on framework-specific entity selectors.

[0134] For client information that is not easily obtained through the Selector mechanism, such as anchor points in the current webpage address, window scroll position, view width, offset, hostname, etc., since the test program and the system under test run in the same environment, the ClientFunction API can be used to obtain the environment information of the system under test. This method makes the acquisition of target elements no longer limited to the Selector, making the script content more flexible.

[0135] To achieve the separation of data and business logic—meaning that when page elements or design change, we only need to maintain the target elements in the page element module—this invention organizes the target elements involved in the entire business process using the page element module pattern. A Page class is declared in the JS test script file. In the constructor of the Page class, all target elements involved in the test business logic are defined using selectors, class names, IDs, or text content. Instances of these elements are then exported in the test script file for reference in other business applications.

[0136] The third step is to build the test script file using a data-driven approach.

[0137] Based on the exported instance data and specific business processes, test cases with the same scenario but different data are written using a data-driven testing model, so as to achieve the requirement that one test case covers multiple test scenarios.

[0138] In addition, an OCR library based on feature extraction methods is called to read random CAPTCHA data created by canvas, thereby enabling automatic login to the web application.

[0139] The test cases include assertion timeout settings. For asynchronous operations like HTTP requests, the Promise constructor returns the asynchronous execution result, triggering the bound callback function based on the result. Alternatively, the `await` keyword can be used to specify subsequent operations that depend on the asynchronous operation result. When executing the test script, the actual result is compared with the expected result using assertion methods, such as whether it matches the expected type, whether it contains a DOM node, and whether the number of nodes is the same. For asynchronous operation results, an assertion timeout must be set in the assertion method. If the assertion fails, the test is not directly marked as successful or unsuccessful; the assertion will be retried multiple times, retrieving the actual property value with each request. If the assertion timeout still fails, the test case fails. The test results are sent to the browser driver in HTML or Report format, and the final test report is saved in the storage path specified in the configuration file.

[0140] The fourth step is to organize the test cases obtained in the previous step in a modular manner to obtain the test script file.

[0141] "Modularization" refers to setting the execution conditions of test cases through API hooks. This includes setting a common initial page URL, the initialization state after each test case execution, and pre- or post-operations for each test case. This modularizes each test case, ensuring logical isolation between them. Test cases can be tested independently without depending on other test cases, improving testing efficiency. Furthermore, when maintaining test cases, only the current test case needs to be maintained, eliminating the need to maintain multiple test cases simultaneously, thus simplifying maintenance.

[0142] Fifth, execute the test script file according to the business scenario.

[0143] For various use cases, this invention can execute one or more test script files with a single click via a local command line; or upload the test script files to an automated device and start the test cases through a GUI interface; or deploy the test scripts in a container to meet the need to run tests on a remote Linux host terminal.

[0144] Locally, test scripts can be executed with a single command line click. This method allows for the execution of one or more test script files, making it convenient for developers. If other test developers are involved, test script files can be uploaded to the corresponding category through the test case creation unit in the automation device. Once all instances are uploaded, they can be executed with a single click using the system's start button. This can be repeated multiple times, and the results in the test operation report provide relatively accurate performance values. For scenarios where no browser is installed on the local host, test cases can still be executed. This invention deploys test scripts in a container, enabling headless testing using Chrome or Firefox on a remote Linux host terminal, with the browser running via command line within the container.

[0145] Step 6: Output the test report.

[0146] Execute the test script file and generate a test report according to the test report format specified in the configuration file.

[0147] This embodiment enables interaction between the test script file and the application under test within the browser by executing the test script file pointed to by the first parameter in the configuration file. The test script file can reach the application under test without going through cumbersome interaction processes such as domain name resolution and three-way handshake, thus achieving efficient testing. Furthermore, the browser does not need to install WebDriver, saving testing time and improving efficiency. Compared to existing testing frameworks that locate target elements, this embodiment can obtain content related to the webpage's operating system environment variables through the Client Function API, expanding the limitations of current selectors. It also provides a timeout waiting mechanism when retrieving target elements, resulting in higher test stability. For testing scenarios requiring CAPTCHA login, compared to existing testing frameworks that need to set cookies in the request header to skip user authentication, this embodiment calls an OCR library to automatically recognize the CAPTCHA and submit it along with user information to the server via a form, achieving automated login and testing. Compared to existing testing frameworks that integrate data and specific business logic into script writing, this embodiment organizes test cases using page element modules, achieving separation of data and specific business logic. For scenarios involving changes in web design or content, only the data script needs to be maintained, reducing code redundancy in locating target elements and facilitating later maintenance. For tests with identical scenarios, this embodiment uses a data-driven testing model to write test cases. By importing driving data into test cases, a single test case can cover multiple test scenarios. It also supports adding assertion timeouts to test cases, reducing the impact of network and environmental factors on test results, making testing more flexible, covering more scenarios, and increasing reliability.

[0148] refer to Figure 3 , Figure 3 This is a schematic diagram of a script file generation process provided by an embodiment of the present invention. The script file generation process includes:

[0149] Import the target element instance.

[0150] Declare a Page class in the JS data script file. In the constructor of the Page class, define all target elements involved in the test business logic, such as target1, target2, etc., through selectors, class names, ids, or text content. Export its instances in the data script file so that they can be referenced in other business programs.

[0151] Import driver data.

[0152] In the business logic script file, import the Page class instance exported in the above steps. For test cases with the same business logic, this invention constructs driving data through a data-driven testing model and introduces it into the script logic file. This model allows for updating the driving data only to meet the test requirements of scenario expansion, making the logic code easier to maintain.

[0153] The controller function performs logical operations on the target element.

[0154] The controller function executes the corresponding operation based on the logic, including clicking, typing, scrolling, etc.

[0155] Determine if it is asynchronous.

[0156] Determine whether the test script file contains asynchronous operations.

[0157] Call the Promise constructor.

[0158] If it is asynchronous, for asynchronous operations like HTTP requests, the Promise constructor is called to return the result of the asynchronous operation, and the bound callback function is triggered based on the result of the asynchronous operation. Alternatively, the await keyword can be used to set subsequent operations that depend on the result of the asynchronous operation.

[0159] If it is not asynchronous, set the assertion through the controller function.

[0160] Determine whether the expected results are consistent with the test results.

[0161] After the operation is completed, the controller function needs to call the assertion API to compare the actual operation result with the expected result through assertion methods, such as determining whether it meets the expected type, whether it contains a certain DOM node, and whether the number of nodes is equal.

[0162] If the expected results match the test results, output a test report; if they do not match, determine whether the assertion time has been exceeded.

[0163] For operations that return results asynchronously, an assertion timeout needs to be set in the assertion method. If the assertion fails, the test will not be marked as successful or failed directly. The assertion will be retried multiple times, and the actual attribute value will be obtained in each request. If the test still fails to pass the verification after the assertion timeout, the test case will fail.

[0164] If the assertion timeout is exceeded, output a test report.

[0165] The test results are sent to the browser driver in HTML or Reporter format, and the final test report is saved in the path set in the configuration file.

[0166] refer to Figure 4 , Figure 4 This is a schematic diagram of a web application automation device provided in an embodiment of the present invention. Figure 4 As shown, the web application automation device consists of a user login module, a user management module, a category management module, and a creation module.

[0167] The user login module enables users to log in to the system using their username and password.

[0168] The user management module is divided into administrators and regular users. Administrators can add and delete users and grant permissions to different accounts. Administrators are further divided into monitors and operators. Monitors can only view tests and download reports through this device and cannot manipulate test script files.

[0169] The category management module allows test script files to be categorized by function. Test script files belonging to the same category are grouped together. This module displays a list of test script files. Each test script file's list consists of the script function, script name, upload time, execution duration, and an operation bar. The operation bar allows users to perform operations such as starting, pausing, deleting, and viewing results for test script files. Clicking the "Execute All" button in a category will execute all test script files within that category, or you can execute a single test script file. The operation bar also allows you to pause test script execution, view execution results, delete test script files, and add test script files to a category by clicking the "Create" button in the category list management module.

[0170] The creation module includes a category selection dropdown, an instance function description input box, and a script name input box. Developers can click the browse button to load locally written instance script files, and then click upload. After successful upload, the test script file will be displayed under the corresponding category.

[0171] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0172] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0173] It should be noted that the technical solutions described in the embodiments of the present invention can be combined arbitrarily without conflict.

[0174] In addition, in the embodiments of the present invention, "first," "second," etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0175] refer to Figure 5 , Figure 5 This is a schematic diagram of a web application testing device provided in an embodiment of the present invention, such as... Figure 5 As shown, the device includes a matching module and a combination module.

[0176] The positioning module is used to locate the target element of the application under test based on a set selector; the application under test is a web application.

[0177] The first generation module is used to generate at least one page element module based on the target element; each page element module represents a set of target elements corresponding to a test page of the application to be tested;

[0178] The second generation module is used to generate at least two test cases for the corresponding test page based on the attribute values ​​of the target element in the page element module.

[0179] The third generation module is used to organize the at least two test cases and generate at least one test script file corresponding to each test page.

[0180] An execution module is used to execute the at least one test script file to test the application to be tested.

[0181] In one embodiment, the second generation module generates at least two test cases for the corresponding test page based on the attribute values ​​of the target element in the page element module, including:

[0182] The driving data for each of the at least two test cases is determined based on a data-driven approach.

[0183] Based on the attribute values ​​of the target elements in the page element module, the driving data, and the business logic of each functional module of the test page, at least two test cases are generated corresponding to each functional module of the test page; the test page includes at least one functional module.

[0184] Correspondingly, the organization of the at least two test cases generates at least one test script file corresponding to each test page, including:

[0185] Deploy at least two test cases corresponding to the same functional module in the same test script file, where each test case in the test script file corresponds to a test scenario.

[0186] In one embodiment, the third generation module generates at least one test script file corresponding to each test page, including:

[0187] Set the assertion timeout in the test script file corresponding to the test case whose execution result is asynchronous.

[0188] In one embodiment, the third generation module organizes the at least two test cases, including:

[0189] Based on the Hook function, set the pre-execution operation and / or post-execution operation for each test case.

[0190] In one embodiment, the third generation module, based on a Hook function, sets pre-execution operations and / or post-execution operations for each test case, including:

[0191] If the execution of the first test case depends on the execution result of the second test case, then the dependency condition of the first test case is set based on the Hook function; the dependency condition represents the execution result of the second test case; the at least two test cases include: the first test case and the second test case.

[0192] In one embodiment, the device further includes:

[0193] The determination module is used to determine the setting selector based on the technology stack of the application under test; the setting selector corresponds to the technology stack of the application under test.

[0194] In one embodiment, the device further includes:

[0195] The configuration module is used to configure the first parameter of the configuration file corresponding to the application under test; the first parameter represents the path of the test script file corresponding to each page element module.

[0196] Correspondingly, the execution module executes the at least one test script file to test the application under test, including:

[0197] Get the first parameter from the configuration file of the application to be tested;

[0198] Execute at least one test script file based on the first parameter.

[0199] In practical applications, the matching module and the combination module can be implemented by processors in electronic devices, such as central processing units (CPUs), digital signal processors (DSPs), microcontroller units (MCUs), or field-programmable gate arrays (FPGAs).

[0200] It should be noted that the Web application testing device provided in the above embodiments is only illustrated by the division of the modules described above. In actual applications, the above processing can be assigned to different modules as needed, that is, the internal structure of the device can be divided into different modules to complete all or part of the processing described above. In addition, the Web application testing device and the Web application testing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0201] The aforementioned web application testing device can be in the form of an image file. After execution, the image file can run as a container or virtual machine to implement the web application testing method described in this application. However, it is not limited to the image file format; any software form capable of implementing the web application testing method described in this application is within the scope of protection of this application. For example, it can also be a software module implemented in a hypervisor (virtual machine monitor) in a cloud computing platform.

[0202] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device, wherein the above Web application testing method is implemented by the processor of the electronic device. Figure 6 This is a schematic diagram of the hardware structure of the electronic device according to an embodiment of this application, as shown below. Figure 6 As shown, the electronic device includes:

[0203] A communication interface enables information exchange with other devices, such as network devices.

[0204] The processor, connected to the communication interface, enables information interaction with other devices and, when running a computer program, executes the methods provided by one or more technical solutions on the electronic device side. The computer program is stored in memory.

[0205] Of course, in practical applications, the various components in an electronic device are coupled together through a bus system. It can be understood that the bus system is used to achieve communication and connection between these components. In addition to the data bus, the bus system also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 6 The general will label all buses as bus systems.

[0206] In this application, the electronic device can be a single hardware device or a cluster of multiple hardware devices, such as a cloud computing platform. A cloud computing platform is a cluster device that organizes multiple independent server physical hardware resources into a pool of resources, providing the necessary virtual resources and services to the outside world.

[0207] The memory in this application embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0208] It is understood that memory can be volatile or non-volatile, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0209] This invention also provides a cloud computing platform, including a data processing software module for a web application testing method, the data processing software module being used to implement the steps of the web application testing method provided in this invention.

[0210] Cloud computing platforms are a business model that uses compute virtualization, network virtualization, and storage virtualization technologies to organize multiple independent server physical hardware resources into a pool of resources. It is a software-defined resource structure based on virtualization technology, capable of providing resource capabilities in the form of virtual machines and containers. By eliminating the fixed relationship between hardware and operating systems, relying on network connectivity for unified resource scheduling, and then providing the necessary virtual resources and services, it represents a new IT software delivery model characterized by flexibility, elasticity, distributed nature, multi-tenancy, and on-demand capabilities.

[0211] Current cloud computing platforms support several service models:

[0212] SaaS (Software as a Service): Cloud computing platform users do not need to purchase software, but instead rent software deployed on the cloud computing platform. Users do not need to maintain the software, as the software service provider will manage and maintain the software in its entirety.

[0213] PaaS (Platform as a Service): Cloud computing platform users (usually software developers) can build new applications or extend existing applications on the architecture provided by the cloud computing platform without having to purchase development, quality control or production servers.

[0214] IaaS (Infrastructure as a Service): Cloud computing platforms provide data centers, infrastructure hardware and software resources via the Internet. Cloud computing platforms under the IaaS model can provide servers, operating systems, disk storage, databases and / or information resources.

[0215] The methods disclosed in the embodiments of this application can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor may be a general-purpose processor, a DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory. The processor reads the program from the memory and, in conjunction with its hardware, completes the steps of the aforementioned method.

[0216] Optionally, when the processor executes the program, it implements the corresponding processes implemented by the electronic device in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0217] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a first memory storing a computer program, which can be executed by a processor of an electronic device to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

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

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

[0220] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0221] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0222] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0223] It should be noted that the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0224] In addition, in this application example, terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0225] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of testing a web application, characterized by, The method includes: The target element of the application under test is located based on a set selector; the application under test is a web application. At least one page element module is generated based on the target element; each page element module represents a set of target elements corresponding to a test page of the application to be tested; Based on a data-driven model, determine the driving data for each test case in at least two test cases; based on the attribute values ​​of the target elements in the page element module, the driving data, and the business logic of each functional module of the test page, generate at least two test cases corresponding to each functional module of the test page; the test page includes at least one of the functional modules. At least two test cases corresponding to the same functional module are deployed in the same test script file, wherein each test case in the test script file corresponds to a test scenario; Configure the first parameter of the configuration file corresponding to the application to be tested; the first parameter represents the path of the test script file corresponding to each page element module; the first parameter in the configuration file refers to the src attribute of the script tag, and the src attribute is used to specify the URL of the external script file; Obtain the first parameter from the configuration file corresponding to the application under test; based on the first parameter in the hypertext markup language file corresponding to the application under test, execute at least one of the test script files to test the application under test; the first parameter in the hypertext markup language file points to the address of at least one of the test script files.

2. The method of claim 1, wherein, The method further includes: Set the assertion timeout in the test script file corresponding to the test case whose execution result is asynchronous.

3. The method according to claim 1, characterized in that, The method further includes: Based on the hook function, pre-execution operations and / or post-execution operations are set for each of the test cases.

4. The method according to claim 3, characterized in that, The setting of pre-execution operations and / or post-execution operations for each test case based on the hook function includes: If the execution of the first test case depends on the execution result of the second test case, then the dependency condition of the first test case is set based on the hook function; the dependency condition represents the execution result of the second test case; the at least two test cases include: the first test case and the second test case.

5. The method according to claim 1, characterized in that, Before locating the target element of the application under test based on the set selector, the method further includes: The setting selector is determined based on the technology stack of the application under test; the setting selector corresponds to the technology stack of the application under test.

6. A web application testing device, characterized in that, include: The positioning module is used to locate the target element of the application under test based on a set selector. The application to be tested is a web application; The first generation module is used to generate at least one page element module based on the target element; Each of the page element modules represents a set of target elements corresponding to a test page of the application under test; The second generation module is used to determine the driving data for each test case in at least two test cases based on the data-driven model. Based on the attribute values ​​of the target elements in the page element module, the driving data, and the business logic of each functional module of the test page, at least two test cases are generated corresponding to each functional module of the test page; the test page includes at least one of the functional modules. At least two test cases corresponding to the same functional module are deployed in the same test script file, wherein each test case in the test script file corresponds to a test scenario; The configuration module is used to configure the first parameter of the configuration file corresponding to the application under test; the first parameter represents the path of the test script file corresponding to each page element module; the first parameter in the configuration file refers to the src attribute of the script tag, and the src attribute is used to specify the URL of the external script file; Obtain the first parameter from the configuration file corresponding to the application under test; based on the first parameter in the hypertext markup language file corresponding to the application under test, execute at least one of the test script files to test the application under test; the first parameter in the hypertext markup language file points to the address of at least one of the test script files.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the Web application testing method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the Web application testing method as described in any one of claims 1 to 5.

Images