A method for automatic testing of web application firewall proxy response times

Abstract

The application relates to the technical field of firewall testing, in particular to a kind of automatic testing method for response time of Web application firewall proxy, comprising: extracting all basic elements in the page to be tested, obtaining the business semantic function of each basic element; based on all basic elements and business semantic function, construct multiple effective function paths; input each effective function path into user behavior sequence model, quantify the transition probability between different effective function paths, based on the transition probability between different effective function paths and high-frequency scene business template, construct at least one typical user behavior chain; based on each typical user behavior chain, generate the attack vector set corresponding to each typical user behavior chain, inject each attack vector set into the corresponding typical user behavior chain to generate a test case set; based on the test case set, test the page to be tested to obtain the response time test result. It greatly improves the test efficiency of Web firewall and the accuracy of test result.

Description

Technical Field

[0001] This application relates to the field of firewall testing technology, and in particular to an automatic testing method for the response time of a Web application firewall proxy. Background Technology

[0002] With the increasing demand for web application security, Web Application Firewalls (WAFs) have been widely deployed in various network services to defend against common network attacks such as SQL injection, cross-site scripting, and file inclusion. As a proxy layer device, the proxy response time of a WAF directly affects the overall access efficiency, user experience, and system stability of web services, making it a key indicator for measuring WAF performance and protection quality. Therefore, efficient and accurate testing of WAF proxy response time has become an important part of the security product deployment and maintenance process.

[0003] However, current testing methods in the industry largely rely on manual operations. Testers need to manually scrape numerous URL lists from the system under test, manually write test cases, and then execute them multiple times to obtain results. However, as WAF applications grow in scale and business logic becomes increasingly complex, this manual approach not only leads to a surge in workload and low execution efficiency, but also struggles to simulate real user behavior involving continuous redirects and concurrent requests. This results in test results that deviate from actual conditions and fail to meet the performance evaluation requirements of modern web applications. Summary of the Invention

[0004] (a) Technical problems to be solved

[0005] In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides an automatic testing method for the proxy response time of a Web application firewall, which solves the technical problem that traditional manual testing methods are inefficient and cannot simulate real user behavior, thus failing to meet the performance testing requirements of Web application firewalls.

[0006] (II) Technical Solution

[0007] To achieve the above objectives, the main technical solutions adopted in this application include:

[0008] In a first aspect, embodiments of this application provide an automatic testing method for the proxy response time of a Web application firewall, comprising:

[0009] Based on the access address of the page under test, extract all basic elements of the page under test, and perform NLP semantic intent recognition on each basic element to obtain the business semantic function corresponding to each basic element.

[0010] Based on each basic element and the corresponding business semantic function, multiple effective functional paths are constructed. The effective functional path is an ordered sequence of multiple basic elements with continuous business semantic functions, arranged in the order of business semantic functions.

[0011] Each effective functional path is input into a pre-configured user behavior sequence model to quantify the jump probability between different effective functional paths. Based on the jump probability between different effective functional paths and the pre-configured high-frequency scenario business template, at least one typical user behavior chain is constructed, wherein the typical user behavior chain includes at least one effective functional path.

[0012] Based on all the basic elements and corresponding business semantic functions in each typical user behavior chain, an attack vector set corresponding to each typical user behavior chain is generated, and each attack vector set is injected into the corresponding typical user behavior chain to generate a test case set.

[0013] The page under test is tested based on the test case set to obtain the response time test results of the page under test.

[0014] Optionally, based on the access address of the page under test, all basic elements of the page under test are extracted, including:

[0015] Based on the access address of the page under test, the static structure of the page under test is traversed through the DOM parsing algorithm to extract all static structural elements on the page under test. Then, the page under test is dynamically rendered based on a pre-set headless browser to extract all dynamic structural elements on the page under test. Each of the basic elements is either a static structural element or a dynamic structural element, and each static structural element and each dynamic structural element includes a corresponding URL identifier.

[0016] Optionally, NLP semantic intent recognition is performed on each basic element to obtain the business semantic function corresponding to each basic element, including:

[0017] Based on the URL identifier corresponding to each of the static structural elements and each of the dynamic structural elements, the content element corresponding to each URL identifier is extracted, wherein the content element includes page text, button labels or form prompts.

[0018] Perform NLP semantic intent recognition on each of the content elements to obtain the business semantic function corresponding to each URL identifier.

[0019] Optionally, based on each basic element and the corresponding business semantic function, multiple effective functional paths are constructed, including:

[0020] Based on the business semantic function corresponding to each basic element, each basic element is filtered to eliminate basic elements whose business semantic function has no practical meaning.

[0021] Based on the business semantic functions corresponding to the filtered basic elements, the logical relationships between different basic elements are confirmed.

[0022] Based on the logical connections between different basic elements, multiple effective functional paths are constructed.

[0023] Optionally, based on all basic elements and corresponding business semantic functions in each typical user behavior chain, an attack vector set corresponding to each typical user behavior chain is generated, including:

[0024] Based on all the basic elements and corresponding business semantic functions in each typical user behavior chain, as well as the pre-set abstract syntax tree algorithm, the parameter type and data structure corresponding to each basic element in each typical user behavior chain are obtained.

[0025] Based on the business semantic function corresponding to each basic element in each typical user behavior chain, and the pre-set threat model invocation strategy, obtain at least one threat model corresponding to each typical user behavior chain.

[0026] Based on at least one threat model corresponding to each typical user behavior chain, and the parameter type and data structure corresponding to each basic element in each typical user behavior chain, an attack vector set corresponding to each typical user behavior chain is created, wherein the attack vector set includes multiple attack payload variants.

[0027] Optionally, each attack vector set is injected into the corresponding typical user behavior chain to generate a test case set, including:

[0028] Each attack vector set is injected into the corresponding typical user behavior chain, and a test case set is generated based on a pre-set test case generation strategy. The test case generation strategy is used to generate baseline test cases without attack payload variant injection, attack test cases with full-link injection attack payload variants, and hybrid test cases with partial-step injection attack payload variants.

[0029] The generated test cases are tested and iteratively optimized until the pre-set optimization goal or iteration limit is reached.

[0030] Optionally, the page under test is tested based on the test case set to obtain the response time test results of the page under test, including:

[0031] Feature extraction and vectorization are performed on the test case set, pre-set test objectives, WAF configuration information and historical performance data to obtain WAF test case feature vectors;

[0032] The WAF test case feature vector is input into a pre-trained reinforcement learning model to obtain multiple test case recommendation schemes. The reinforcement learning model is used to model the test case selection and ranking problem as a Markov decision process and solve the Markov decision process to generate multiple test case recommendation schemes.

[0033] The system visualizes the recommended solutions for multiple use cases and generates the final execution plan based on the received user feedback.

[0034] Based on the final execution plan, the pre-set test environment, and structured constraints, the page under test is tested to obtain the response time test results.

[0035] Optionally, based on the final execution plan, a pre-set test environment, and structured constraints, the page under test is tested to obtain response time test results, including:

[0036] Based on the final execution plan, the pre-set test environment, and the structured constraints, simulate sending HTTP / HTTPS requests to the page under test;

[0037] During the sending of HTTP / HTTPS requests, client timestamp data and WAF log data are obtained in real time;

[0038] The client timestamp data and WAF log data are calibrated based on a pre-set network latency compensation algorithm and clock synchronization strategy, and the WAF proxy response time is calculated based on the calibrated WAF log data.

[0039] Optionally, during the sending of an HTTP / HTTPS request, the method further includes:

[0040] The system acquires WAF status data, response time metrics, and test result evaluation metrics in real time, and adjusts the test environment and final execution plan in real time based on the WAF status data, response time metrics, and test result evaluation metrics.

[0041] Optionally, after obtaining the response time test results of the page under test, the method further includes:

[0042] The response time test results of the tested page are post-processed, and a corresponding test result report is generated based on the post-processing results;

[0043] The test result report is processed for notification based on a pre-set notification strategy.

[0044] (III) Beneficial Effects

[0045] This application presents an automated testing method for Web Application Firewall (WAF) proxy response time. It automatically crawls the basic elements of the page under test and performs semantic recognition to intelligently understand the page's business functions, thereby constructing an effective functional path. Furthermore, it generates typical user behavior chains that realistically simulate user behavior through a user behavior sequence model. Based on this, it dynamically generates targeted attack vector sets for each behavior chain and injects them into the test. This achieves full automation from automatic test case generation and multi-scenario simulation to response time collection. This method not only significantly improves the testing efficiency of Web firewalls but also realistically recreates real user operations and attack protection scenarios, significantly improving the accuracy of Web firewall test results. Attached Figure Description

[0046] Figure 1 A flowchart of an automatic testing method for Web application firewall proxy response time provided in an embodiment of this application;

[0047] Figure 2 The execution flowchart of the use case generation module provided in the embodiments of this application is shown below;

[0048] Figure 3 This is a flowchart of the test execution module provided in an embodiment of this application;

[0049] Figure 4 This document provides an execution flowchart for an automated testing system for Web application firewall proxy response time, as illustrated in an embodiment of this application. Detailed Implementation

[0050] To better explain and facilitate understanding of this application, the following detailed description of the application is provided in conjunction with the accompanying drawings and specific embodiments.

[0051] With the increasing demand for web application security protection, Web Application Firewalls (WAFs), as critical web security protection devices, directly impact service efficiency and user experience through their proxy response time. This is a core indicator for evaluating performance and protection quality, making efficient and accurate response time testing particularly important. However, current industry testing largely relies on manual URL crawling, test case writing, and repeated execution. This is not only labor-intensive and inefficient but also fails to simulate the continuous redirection and concurrent behavior of real users, leading to test results that deviate from reality and are ill-suited to the performance evaluation requirements of today's complex web applications.

[0052] Therefore, embodiments of this application provide an automatic testing method for the proxy response time of a Web application firewall, such as... Figure 1 As shown, it includes:

[0053] S1. Based on the access address of the page under test, extract all basic elements of the page under test, and perform NLP semantic intent recognition on each basic element to obtain the business semantic function corresponding to each basic element.

[0054] S2. Based on each basic element and the business semantic function corresponding to each basic element, construct multiple effective functional paths. Among them, the effective functional path is an ordered sequence of multiple basic elements with continuous business semantic functions in accordance with the order of business semantic functions.

[0055] S3. Input each effective functional path into the pre-configured user behavior sequence model to quantify the jump probability between different effective functional paths, and construct at least one typical user behavior chain based on the jump probability between different effective functional paths and the pre-configured high-frequency scenario business template. The typical user behavior chain includes at least one effective functional path.

[0056] S4. Based on all basic elements and corresponding business semantic functions in each typical user behavior chain, generate an attack vector set for each typical user behavior chain, and inject each attack vector set into the corresponding typical user behavior chain to generate a test case set.

[0057] S5. Test the page under test based on the test case set to obtain the response time test results of the page under test.

[0058] This application provides an automated testing method for the proxy response time of a Web application firewall. It automatically crawls the basic elements of the page under test and performs semantic recognition to intelligently understand the page's business functions, thereby constructing an effective functional path. Furthermore, it generates typical user behavior chains through a user behavior sequence model to realistically simulate user behavior. Based on this, it dynamically generates targeted attack vector sets for each behavior chain and injects them into the test, achieving full automation from automatic test case generation and multi-scenario simulation to response time collection. This method not only significantly improves the testing efficiency of Web firewalls but also realistically recreates real user operations and attack protection scenarios, significantly improving the accuracy of Web firewall test results.

[0059] Optionally, in one specific embodiment, based on the access address of the page under test, all basic elements of the page under test are extracted, including:

[0060] S11. Based on the access address of the page under test, traverse the static structure of the page under test through the DOM parsing algorithm, extract all static structural elements on the page under test, and dynamically render the page under test based on the pre-set headless browser to extract all dynamic structural elements on the page under test. Each basic element is either a static structural element or a dynamic structural element, and each static structural element and each dynamic structural element includes a corresponding URL identifier.

[0061] Specifically, firstly, it is necessary to extract the static structural elements of the page under test. Static structural elements refer to page structure and communication elements that can be directly parsed and extracted from the HTML source code without relying on front-end script execution. These include, but are not limited to: URL identifiers (main page URL, URLs of static tags, etc.), DOM node structure / parameter characteristics, static request parameters / header classes, and static HTTP communication attributes. The process of extracting the static structural elements of the page under test includes the following steps:

[0062] Obtain the access address of the page under test, initiate an HTTP request to download the original HTML source code. Load a DOM parsing algorithm (such as Python's ixml library or JavaScript's DOMparser) to perform syntax parsing on the original HTML source code and construct a static DOM tree. Then, by traversing all nodes of the DOM tree, extract various static structural elements layer by layer, i.e.:

[0063] Analysis 、 <form> , <link> Extract URL identifiers (such as href / action attribute values) from tags; parse... <input> , <button>、 Extract names, attributes (id / name / type), and static parameter values ​​from tags such as [tag name]; record the URL relationships of all elements (such as the main URL of the page to which a static button belongs).

[0064] After extracting various static structural elements layer by layer, the extracted static structural elements are stored in a structured manner (such as in JSON format) and labeled with corresponding tags, such as "static type tags", to ensure that each element is associated with a corresponding URL identifier.

[0065] Next, dynamic structural elements are extracted. These dynamic structural elements (i.e., the basic elements generated after script execution) refer to structural and communication elements that are generated only after the front-end JS script is executed and the page is dynamically rendered. These include, but are not limited to: URL identifiers (asynchronous URLs dynamically generated by JS), dynamic DOM nodes (interactive elements generated by JS rendering, such as forms in pop-ups, lazy-loaded buttons / input boxes, etc.), dynamic request parameters (request parameters dynamically concatenated by JS), and dynamic HTTP communication attributes. The process of extracting dynamic structural elements includes the following steps:

[0066] Configure a headless browser environment (such as Chrome Headless, Playwright, Puppeteer), load the access address of the page under test, and simulate the execution flow of a real browser through the headless browser: load HTML source code → execute all JS scripts on the page (including asynchronously loaded scripts) → render the complete dynamic page (including pop-ups, asynchronous request results, etc.).

[0067] After dynamic rendering is complete, the dynamic DOM tree is obtained through the headless browser's API. The dynamic DOM tree is traversed to extract all dynamic structural elements that were not obtained during the static parsing phase, such as:

[0068] Parsing dynamically generated JS Extract dynamically generated URL identifiers from tags or AJAX request configurations; parse interactive elements rendered by JS (such as login forms in dynamic pop-ups, payment buttons that appear after clicking), and extract tag attributes and dynamic parameters; capture all asynchronous requests (XHR / fetch) during page loading, and record request URLs, dynamic parameters, and request headers.

[0069] After extracting dynamic structural elements, the extracted dynamic structural elements are stored in a structured manner, labeled with "dynamic type", and associated with the corresponding URL identifier (such as the business module URL to which a certain dynamic interface URL belongs).

[0070] Finally, the static and dynamic structural elements are integrated, specifically including:

[0071] Merge the sets of static and dynamic structural elements, and remove duplicate elements; supplement the main URL of the associated page for elements with missing URL identifiers; output a complete set of basic elements (static + dynamic) as the data source for subsequent NLP semantic intent recognition and construction of effective functional paths.

[0072] In this embodiment of the application, when extracting basic elements of the page under test, static structural elements are first extracted through DOM parsing, and then dynamic structural elements are extracted by rendering with a headless browser. After merging, deduplication, and URL identifier verification and supplementation, a complete set is output. This method achieves full coverage of static and dynamic elements, ensuring completeness. Furthermore, structured storage and verification improve the accuracy and efficiency of extraction, providing a high-quality data source for subsequent testing stages, thereby ensuring the smooth progress of automated testing and the accuracy of results.

[0073] Optionally, in a specific embodiment, NLP semantic intent recognition is performed on each basic element to obtain the business semantic function corresponding to each basic element, including:

[0074] S12. Based on the URL identifier corresponding to each static structural element and each dynamic structural element, extract the content element corresponding to each URL identifier, wherein the content element includes page text, button label or form tooltip.

[0075] S13. Perform NLP semantic intent recognition on each content element to obtain the business semantic function corresponding to each URL identifier.

[0076] Specifically, the content elements corresponding to each URL identifier are extracted. This involves identifying the elements representing the functional intent of the page based on the URL identifier within static / dynamic structural elements, providing data support for subsequent NLP recognition. URL identifiers include both static and dynamic identifiers. Content elements are text-based information strongly associated with the URL identifier that reflects the page's functional intent, including but not limited to page text, button labels, and form tooltips. The extraction logic needs to be combined with the page node or functional scenario corresponding to the URL. For example:

[0077] The page text extraction target is the core text of the page corresponding to the URL (such as page title, functional module description text, business introduction text, etc.). The extraction logic is to locate the corresponding page or component node based on the URL, and then extract the text content within the node through DOM parsing (static elements) or dynamic rendering by a headless browser (dynamic elements). Invalid and redundant text (such as advertisements and decorative text) is filtered out. For example, in the page corresponding to the URL / login / , the core text such as "Account Login" and "Please enter username and password" are extracted.

[0078] Button tags, specifically the text tags of buttons and links associated with URLs (such as the text on the button, ...). The anchor text of the tag is extracted using the following logic: locate the interactive button node corresponding to the URL (such as a submit button or a redirect link), and extract its textContent or value attribute value, such as in the login page. < / button> <button type=""submit”"> Log in< / button> "Login" on the payment page <a href="" / pay”"> Confirm payment "Confirm payment", etc.

[0079] Form tooltips specifically extract the tooltips (such as placeholder attributes and form description text) from input fields and selection fields in the form corresponding to the URL. The extraction logic involves targeting the form nodes associated with the URL (such as login forms, registration forms, and search forms), extracting the placeholder attribute of input fields and the description text below the form, such as in login forms. <input placeholder=""请输入手机号”"> The prompts include "Please enter your mobile number".

[0080] Note that when extracting content elements corresponding to each URL identifier, constraints are required, including but not limited to: relevance constraints, which extract only content elements directly related to the URL identifier and exclude general text on the page that has no functional connection; validity constraints, which filter out blank text, duplicate text, and meaningless decorative text (such as vague expressions like "click here" or "more") and retain text that reflects the functional intent; and full coverage constraints, which extract content elements corresponding to static URLs directly through DOM parsing and extract content elements corresponding to dynamic URLs through the page API after dynamic rendering in a headless browser to ensure that no static or dynamic scenarios are missed.

[0081] Subsequently, NLP semantic intent recognition is performed on the content elements to obtain business semantic functions. The extracted content elements are then classified using NLP technology, ultimately mapping them to the corresponding business semantic functions of the URLs. Specifically, this includes:

[0082] The extracted content elements are cleaned (special characters, spaces, and redundant words are removed), segmented (Chinese and English words), and feature extracted (text keywords and semantic vectors are extracted). The preprocessed text is matched with a pre-defined "functional intent tag library," which covers common business functions of web applications, such as authentication, form submission, search, payment, file upload, data query, and order submission. For fuzzy text (such as "settle immediately" or "confirm order"), the most fitting intent tag is matched through semantic similarity calculation (such as cosine similarity). A unique or set of core intent tags are output for each URL identifier as its business semantic function.

[0083] In addition, the classification of business semantic functions needs to consider certain mapping rules. Business semantic functions are standardized descriptions of the core purpose of URLs. The specific classification and mapping rules are as follows:

[0084] Authentication-related keywords include, but are not limited to, login, registration, password retrieval, and logout. Their content elements include text such as "login", "register", "password retrieval", "logout", "account", "password", and "verification code". Corresponding URL examples include / login (login), / register (register), and / forget-password (retrieve password).

[0085] Form submissions have core intent tags including but not limited to submit, save, confirm, and modify. Their content elements include text such as "submit," "save," "confirm," "modify," "edit," and "update." Corresponding URL examples include / user / profile / save (save personal information) and / order / edit / submit (submit order modification).

[0086] In addition, business semantic functions can be categorized into search, payment transaction, text operation, browsing and viewing, and order operation, which will not be listed here.

[0087] After identification, a "URL-business semantic function" mapping relationship is constructed for each URL identifier, forming a "page function tag library" in dictionary format. Each URL's corresponding business semantic function can contain one or more core tags, comprehensively covering its functional scenarios. This tag library will serve as data support for subsequently constructing effective functional paths and generating typical user behavior chains.

[0088] This embodiment extracts associated content elements based on URL identifiers of static / dynamic structural elements. Then, through NLP semantic intent recognition processes such as text preprocessing, functional intent tag library matching, and semantic similarity optimization, it constructs a standardized "URL-business semantic function" mapping relationship and page function tag library. This not only achieves accurate identification and standardized classification of the core business functions of the URL, providing data support for the subsequent construction of effective functional paths and generation of typical user behavior chains, but also improves the accuracy and reliability of business semantic function recognition by filtering redundant and invalid information and optimizing the accuracy of fuzzy text recognition.

[0089] Optionally, S2 includes:

[0090] S21. Based on the business semantic function corresponding to each basic element, filter each basic element to eliminate basic elements whose business semantic function has no practical meaning.

[0091] S22. Based on the business semantic functions corresponding to the filtered basic elements, confirm the logical relationships between different basic elements;

[0092] S23. Based on the logical relationships between different basic elements, construct multiple effective functional paths.

[0093] Specifically, firstly, it is necessary to filter out the basic elements that are meaningful for the business semantics. The specific process includes:

[0094] Based on whether the business semantic function has clear value in a web application scenario, basic elements without actual functional references are eliminated. For example, objects are retained, while basic elements with clear core tags for their business semantic functions are excluded; these elements correspond to elements effectively categorized in the "page function tag library." Objects without clear tags for their business semantic functions are excluded; these include redundant elements with repetitive and undifferentiated functions, or decorative, auxiliary elements that do not participate in core business processes. The filtered basic elements must meet the requirement of "supporting real user business operations."

[0095] Subsequently, the logical relationships between the different basic elements are determined, specifically including:

[0096] The essence of logical relationships is the sequence of business processes or functional dependencies in a web application. Generally, the relationships are as follows:

[0097] Business process progression: Based on the conventional operation process of web applications, the business semantic function of the previous element is the prerequisite for the next element, such as login (authentication class) → search (search class) → place order (order operation class) → payment (payment transaction class).

[0098] Functional dependency association: The business semantic function of the later element depends on the execution result of the previous element, such as file upload (file operation class) → submit for review (form submission class) (file upload must be completed before submission for review).

[0099] Scenario-based navigation: Function switching within the same business scenario, without strict pre-dependencies but conforming to user operating habits, such as viewing product details (browse / view) → adding to cart (order operation), or personal center (browse / view) → modifying information (form submission).

[0100] Reverse operation association: The reverse flow of core operations, such as placing an order (order operation class) → canceling an order (order operation class), making payment (payment transaction class) → requesting a refund (payment transaction class).

[0101] The logic for confirming associations is as follows: based on business semantic function tag matching, that is, by combining the tags of each element in the page function tag library to deduce the association relationship; or, combined with the URL path structure to assist in the judgment: URLs under the same functional module have process associations by default; or, referring to historical access logs: if there are historical user access logs of SUT, the logical association can be verified and supplemented through the URL access sequence in the log to ensure that the association relationship matches the real user behavior.

[0102] Finally, multiple effective functional paths are constructed. An effective functional path is an ordered sequence composed of multiple basic elements with continuous business semantic functions, arranged in a logically related order.

[0103] The specific rules for path construction are illustrated with the following examples:

[0104] Covering core business scenarios: Prioritizing the construction of paths corresponding to high-frequency business, such as browsing products → logging in → adding to cart → placing an order → payment in e-commerce scenarios, and querying service guides → logging in → uploading materials → submitting applications in government service scenarios; Supporting multiple scenario branches: The same preceding element can correspond to multiple subsequent paths, such as branching after logging in to query orders, modify information, recharge, etc.; Flexible path length adaptation: It can be a short path (2-3 elements) or a long path (5 or more elements); Eliminating invalid paths: Eliminating sequences with logical contradictions or no actual business significance.

[0105] Once the system is built, it outputs a structured set of valid functional paths, with each path presented as a sequence of basic elements and a sequence of business semantic functions.

[0106] This application embodiment filters valid basic elements and eliminates invalid and redundant elements. Then, through business semantic tag matching, URL path assistance, and historical log reference, it identifies multiple logical relationships between elements. Finally, it constructs a structured set of valid functional paths according to rules such as core scenario coverage and multi-branch support. This ensures that the paths are real and valid, and fully covers core business and user operation logic, providing a high-quality path foundation for subsequent generation of typical user behavior chains and accurate injection of attack vectors.

[0107] Optionally, in a specific embodiment, each effective functional path is input into a pre-configured user behavior sequence model to quantify the jump probability between different effective functional paths, and at least one typical user behavior chain is constructed based on the jump probability between different effective functional paths and the pre-configured high-frequency scenario business template, wherein the typical user behavior chain includes at least one effective functional path.

[0108] Specifically, user behavior sequence models preferentially employ Markov chain models, but can also be extended to reinforcement learning models (such as DQN). The probability of transitions between different effective functional paths is quantified through state transition probabilities. Generally, user behavior sequence models are based on historical user access logs of the system under test (SUT), extracting access sequences of URLs / functional paths and statistically analyzing the frequency of transitions between different paths. This serves as the core basis for initial transition probabilities during offline training.

[0109] The model's output uses valid functional paths as state nodes, outputting a probability matrix of transitions between any two paths. The probability values ​​reflect the likelihood of a user jumping from one functional path to another in a real-world scenario. Specifically, static valid functional paths are transformed into dynamic behavioral sequences with probabilities. That is, all valid functional paths are uniquely identified and encoded (e.g., path ID: path_001=browse products, path_002=login, path_003=add to cart), serving as "state nodes" in the user behavior sequence model.

[0110] The encoded set of valid function paths is input into a pre-configured user behavior sequence model. The model, based on built-in training data / general features, statistically analyzes and calculates:

[0111] The frequency percentage of access to a single path (e.g., path_002=login access frequency accounts for 60% of all paths); the probability of conditional redirection between any two paths (e.g., after a user completes path_001=browse products, the probability of being redirected to path_002=login is 70%, and the probability of being redirected to path_004=place an order directly is 5%); finally, a structured path redirection probability table is generated.

[0112] In addition, in constructing a typical user behavior chain by combining jump probability and high-frequency scenario business templates, the typical user behavior chain is a combination of paths that fits the actual user operation habits and covers core business scenarios. The construction process needs to combine probability quantification results and preset templates.

[0113] High-frequency scenario business templates are core business process templates preset based on different web application types. They are the "scenario skeleton" for constructing behavior chains, such as: e-commerce scenario template: "Browse → Login → Add to Cart → Place Order → Pay".

[0114] The rules for constructing typical user behavior chains include, but are not limited to: the probability-first principle, which prioritizes path combinations with a jump probability greater than or equal to a preset threshold (e.g., 70%) within the framework of high-frequency scenario templates, ensuring that the behavior chain aligns with real user operating habits; the scenario coverage principle, which generates at least one long behavior chain covering the core scenario, while also generating multiple branch behavior chains (e.g., e-commerce scenario main chain: browsing → login → adding to cart → placing an order → payment; branch chain: login → order inquiry → refund application); and the path integration principle, which allows typical user behavior chains to contain one or more effective functional paths, supporting the continuous splicing of paths.

[0115] Reasonableness verification: Remove path combinations with extremely low redirection probability (e.g., <5%) and logical contradictions (e.g., payment → login) to ensure that there are no business logic errors in the behavior chain.

[0116] The final result is a set of structured typical user behavior chains, each containing information such as behavior chain ID, path sequence, jump probability sequence, and the corresponding scenario template.

[0117] The typical user behavior chain generated in this application embodiment will directly serve as the core basis for subsequent "generating attack vector sets and injecting test case sets", ensuring that the test cases can simulate the continuous behavior path of real users and improve the authenticity and accuracy of WAF proxy response time testing.

[0118] Optionally, in a specific embodiment, based on all basic elements and corresponding business semantic functions in each typical user behavior chain, an attack vector set corresponding to each typical user behavior chain is generated, including:

[0119] S41. Based on all basic elements and corresponding business semantic functions in each typical user behavior chain, and the pre-set abstract syntax tree algorithm, obtain the parameter type and data structure corresponding to each basic element in each typical user behavior chain.

[0120] S42. Based on the business semantic function corresponding to each basic element in each typical user behavior chain and the pre-set threat model invocation strategy, obtain at least one threat model corresponding to each typical user behavior chain.

[0121] S43. Based on at least one threat model corresponding to each typical user behavior chain, and the parameter type and data structure corresponding to each basic element in each typical user behavior chain, create an attack vector set corresponding to each typical user behavior chain, wherein the attack vector set includes multiple attack payload variants.

[0122] Specifically, the abstract syntax tree (AST) algorithm is used to parse the parameter features of basic elements. The AST algorithm is suitable for URLs, request interfaces or form submission logic corresponding to each basic element (static / dynamic structural element) in a typical user behavior chain. The AST algorithm is used to perform structured parsing of the syntax structure of request parameters.

[0123] The AST algorithm parses the parameter types of the objects corresponding to the basic elements, such as string, numeric (int / float), boolean (bool), array, and object types, as well as the input constraints of the parameters (such as whether special characters are allowed, length limits, and format requirements). The data structure of the parsed objects includes the hierarchical structure of the parameters (such as nested JSON structures), the relationships between parameters (such as the binding relationship between "order number" and "user ID"), and the parameter transmission format (such as form-data, JSON, and XML). The specific parsing process is as follows:

[0124] The system takes basic elements (including URL identifiers and request body / form structure) from a typical user behavior chain as input, transforms the parameter syntax into a tree structure, traverses nodes to extract parameter types and data structure features, and then obtains a mapping table of basic elements, parameter types, and data structures. For example, / login has the business semantic function of authentication (login), parameter types of string / int, and a flat data structure.

[0125] After obtaining the parameter types and data structures corresponding to each basic element in each typical user behavior chain, a suitable threat model is matched according to the business semantic function to ensure that the attack vector fits the functional scenario of the basic element. The core rule of the threat model invocation strategy is to execute according to the logic of "business semantic function classification → matching the corresponding attack type → invoking the dedicated threat model." The strategy must cover common attack scenarios in web applications and be strongly correlated with the functional characteristics of the basic element. Its policy constraints include that the same business semantic function can match multiple threat models (e.g., "login" matches both SQL injection and brute-force models), and different functions match threat models with different priorities (e.g., "payment" prioritizes matching parameter tampering models, and "search" prioritizes matching XSS models). Specific threat model types include, but are not limited to, SQL injection, cross-site scripting (XSS), file inclusion, parameter tampering, brute-force attacks, CSRF (cross-site request forgery), command execution, and path traversal.

[0126] Furthermore, a "behavior chain-threat model list" is generated for each typical user behavior chain. For example, a typical user behavior chain (browsing → login → placing an order → payment) → matches the threat model: SQL injection, XSS, parameter tampering, brute force attack.

[0127] Finally, create an attack vector set containing multiple variant attack payloads. That is, generate multiple different forms of attack payloads (such as the base payload for SQL injection) for the same threat model to avoid incomplete test coverage caused by a single payload; and the attack payload needs to match the parsed parameter type and data structure (such as numeric parameters to adapt to numeric SQL injection payloads, and string parameters to adapt to character XSS payloads).

[0128] Adjust the format of the attack payload according to the parameter type and data structure of the basic element (e.g., for JSON structure parameters, the payload needs to be embedded in the JSON value, and for form parameters, the payload needs to be concatenated according to the form format).

[0129] Each threat model corresponding to each behavior chain generates at least 3-5 payload variants, covering the basic form, variant form, and encoded form, to increase the probability of triggering WAF rules;

[0130] Attack vectors need to align with the business process of typical user behavior chains (e.g., in the "login → order → payment" behavior chain, attack vectors in the payment stage focus on amount tampering, while those in the order stage focus on SQL injection of the order number). This generates a structured mapping relationship of "typical user behavior chain - attack vector set," with each behavior chain corresponding to a set of attack vectors.

[0131] This application's embodiments analyze the parameter types, data structures, and other features of basic elements in a typical user behavior chain using the AST algorithm. Then, it matches corresponding threat models with clearly defined priorities according to business semantic functions. Finally, it combines parameter features and business processes to generate multi-form attack payload variants adapted to different formats, constructing a structured attack vector set. This approach ensures that attack vectors are highly aligned with parameter features, business scenarios, and user behavior, improving the realism and targeting of attack scenarios. Simultaneously, by covering test blind spots with multiple variant payloads, it effectively increases the probability of WAF protection rules being triggered.

[0132] Optionally, in a specific embodiment, each attack vector set is injected into the corresponding typical user behavior chain to generate a test case set, including:

[0133] S44. Inject each attack vector set into the corresponding typical user behavior chain, and generate a test case set based on the pre-set test case generation strategy. The test case generation strategy is used to generate a baseline test case without attack payload variant injection, an attack case with full-link injection attack payload variant, and a hybrid test case with partial-step injection attack payload variant.

[0134] The generated test cases are tested and iteratively optimized until the pre-set optimization goal or iteration limit is reached.

[0135] Specifically, the test case generation strategy uses pre-configured test case classification rules to clarify the injection logic of test cases, ensuring that test cases cover all scenarios including normal, full attack, and hybrid attack scenarios. The pre-configured strategy includes the following steps: directly reusing the original path of a typical user behavior chain without injecting any attack payloads, preserving the integrity and authenticity of user behavior to generate baseline test cases (such as a pure normal process of "browsing products → logging in → adding to cart → placing an order → paying"); injecting payload variants from the corresponding attack vector set into each basic element of the typical user behavior chain, generating multiple sets of attack test cases (corresponding to different payload variants) for the same behavior chain to ensure full-link attack scenario coverage; prioritizing core elements and randomly combining them for supplementation, injecting attack payloads into key basic elements of the behavior chain (such as login, payment, and order placement), while maintaining normal processes in other elements; supporting multiple combination modes (such as injection only in the login stage, or injection in both login and payment stages), with each combination corresponding to a set of hybrid test cases. For the same typical user behavior chain, at least one set of baseline test cases, 3-5 sets of attack test cases, and 5-8 sets of mixed test cases should be generated to ensure comprehensive scenario coverage; the test cases should include metadata such as unique identifier, behavior chain ID, injection payload information, and test target.

[0136] Based on the test case generation strategy configured above, the attack vector set is injected into the corresponding typical user behavior chain, specifically including:

[0137] First, traverse each typical user behavior chain and extract its basic element sequence and business semantic function sequence. Directly convert the original path of the behavior chain into a baseline test case, recording the test case type as "baseline" with no attack payload information. Simultaneously, for each basic element in the behavior chain, select an attack payload variant from the corresponding attack vector set. Adapt the payload to the request parameters of the element according to the parameter type and data structure of the basic element (e.g., embedding JSON values ​​into JSON parameters, concatenating form parameters into payloads). Concatenate all injected basic elements according to the logical order of the behavior chain to form a complete end-to-end attack test case. Repeat the above process, changing different payload variants to generate multiple sets of attack test cases. Also, select some basic elements in the behavior chain according to the strategy (e.g., "login" and "payment" steps). For the selected basic elements, select payload variants from the attack vector set and adapt and inject them. Unselected elements maintain the normal process. Concatenate the injected elements with the normal basic elements according to the logical order of the behavior chain to form mixed test cases. Change the selected steps and payload variants to generate multiple sets of mixed test cases.

[0138] All generated baseline test cases, attack test cases, and hybrid test cases are compiled into a structured test case set.

[0139] Secondly, the generated test case set is submitted for execution, the tests are performed, and feedback data is collected, including:

[0140] Invoke the client agent to simulate sending HTTP / HTTPS requests according to the path sequence and request parameters of the test cases. Iterate through all test cases and record the WAF proxy response time (calculated by request_time-upstream_response_time), WAF interception rate, test case execution success rate, and test coverage (rule coverage / path coverage) for each test case. For test cases that fail to execute (such as request timeout or incorrect parameter format), mark them as "invalid test cases" and record the reasons for failure (such as payload format mismatch or logical contradiction in the behavior chain).

[0141] Finally, based on the collected test feedback data, the test cases are optimized in multiple rounds until the preset goals or iteration limits are reached. This includes: setting optimization goals and iteration limits, i.e., setting the optimization goals as test coverage ≥95%, effective test case ratio ≥90%, and complete WAF interception rate and response time data for attack scenarios (such as payment parameter tampering and login SQL injection); setting iteration limits, i.e., setting the maximum number of iterations (e.g., 5 times) and the threshold for the optimization effect of a single iteration (e.g., stopping if coverage improves by ≥1%); and performing multiple rounds of optimization.

[0142] This application's embodiments generate three types of test cases through a test case generation strategy, achieving full coverage of normal, full attack, and mixed attack scenarios, thus solving the pain point of traditional test case scenarios being too singular. Through multiple rounds of iterative optimization, invalid test cases are eliminated and high-value test cases are optimized to ensure the effectiveness and relevance of test cases, providing high-quality test case support for accurate testing of WAF proxy response time in the future, while improving testing efficiency and result reliability.

[0143] Optionally, in one specific embodiment, the page under test is tested based on a test case set to obtain the response time test results of the page under test, including:

[0144] S51. Perform feature extraction and vectorization on the test case set, pre-set test objectives, WAF configuration information and historical performance data to obtain WAF test case feature vectors;

[0145] S52. Input the WAF test case feature vector into the pre-trained reinforcement learning model to obtain multiple test case recommendation schemes. The reinforcement learning model is used to model the test case selection and ranking problem as a Markov decision process and solve the Markov decision process to generate multiple test case recommendation schemes.

[0146] S53. Visualize the recommended solutions for multiple sets of use cases and generate the final execution plan based on the received user feedback;

[0147] S54. Based on the final execution plan, the pre-set test environment, and structured constraints, test the page under test to obtain the response time test results.

[0148] Furthermore, S54 includes:

[0149] S541. Based on the final execution plan, the pre-set test environment, and the structured constraints, simulate sending HTTP / HTTPS requests to the page under test;

[0150] S542. During the process of sending HTTP / HTTPS requests, obtain client timestamp data and WAF log data in real time;

[0151] S543. Based on the pre-set network latency compensation algorithm and clock synchronization strategy, the client timestamp data and WAF log data are calibrated, and the WAF agent response time is calculated based on the calibrated WAF log data.

[0152] Furthermore, the methods also include the following when sending HTTP / HTTPS requests:

[0153] The system acquires WAF status data, response time metrics, and test result evaluation metrics in real time, and adjusts the test environment and final execution plan accordingly.

[0154] Specifically, firstly, feature extraction and vectorization are performed on the test case set features, as well as pre-set test target features, WAF configuration features, and historical performance data features, to generate WAF test case feature vectors. The test case set features include test case type (baseline / attack / hybrid), attack payload type, associated business semantic functions, parameter complexity, and historical execution success rate; test target features include response time evaluation threshold, test coverage requirements (rule coverage / path coverage), and risk priority (e.g., focusing on testing the payment process); WAF configuration features include the number of protection rules, rule complexity, concurrent connection limit, and caching strategy; historical performance data features include historical average response time, response time variance, rule trigger frequency, and interception rate. Using standardization and normalization methods, the above discrete / continuous features are transformed into fixed-dimensional vectors (e.g., 128-dimensional vectors). A structured set of WAF test case feature vectors is output, with each test case corresponding to a unique feature vector.

[0155] Secondly, the feature vectors obtained above are input into a pre-configured reinforcement learning model to obtain multiple sets of use case recommendation schemes, specifically:

[0156] The feature vectors of WAF test cases are input into a reinforcement learning model (the model's modeling logic treats "selecting test cases → executing tests → obtaining feedback" as a Markov decision process, with the state being the current test progress / environment state, the action being selecting the next test case, and the reward being improved coverage / time savings / result effectiveness) to generate recommended solutions. Each solution includes the test case execution order, concurrency settings, and execution mode (serial / concurrent / mixed load), such as: Solution 1 (Time Priority): Prioritizes the execution of high-frequency business path test cases, with a concurrency setting of 5, and an estimated test time saving of 40%; Solution 2 (Coverage Priority): Includes edge scenario test cases, with a concurrency setting of 3, and an estimated coverage of 98%; Solution 3 (Balanced): Balances time and coverage, with a concurrency setting of 4, and an estimated test time saving of 25% and coverage of 95%.

[0157] Next, the solutions are visualized, and user confirmation is received. Specifically, key metrics for each recommended solution are displayed in chart form, including estimated test duration, coverage, resource utilization, core test case list, and execution order preview. Users can preview the content and choose to accept a solution directly or make partial adjustments (such as modifying concurrency or adding / removing test cases). Based on user feedback, and using a multi-dimensional constraint modeler (which transforms user requirements into constraints), the final execution plan is generated, specifying the test case execution order, concurrency strategy, time window, and resource allocation.

[0158] Furthermore, based on the final execution plan, simulated request tests are conducted to obtain response time test results, namely:

[0159] Based on the final execution plan, initialize the test environment (client agent, network connection, log collection tool); set the client agent to send HTTP / HTTPS requests in the order of test cases, simulating real users, with request parameters including normal parameters or attack payloads from the test cases (adapting parameter types and data structures); set test structure constraints (such as test cases with the same rule set being executed at 1-second intervals to avoid cache interference).

[0160] After setup, testing was conducted, during which timestamps and log data were collected in real time. Specifically, the client agent recorded high-precision timestamps, including the request sending time (T_send) and the complete response reception time (T_recv), and simultaneously tracked six time-consuming metrics such as DNS resolution and TCP connections. WAF log data was read, and core parameters were extracted from the Nginx logs through the client agent, including total client request time, upstream_response_time (upstream server interaction time), and upstream_connect_time. The collected timestamps and log data were then associated and stored by use case ID to ensure traceability.

[0161] In addition, data calibration and WAF agent response time calculation are performed during each round of testing.

[0162] Furthermore, during testing, the testing process is monitored in real time, and adjustments are made based on feedback to ensure the effectiveness of the test. This involves real-time collection and monitoring of the following metrics: WAF status data (CPU / memory utilization, number of connections, error rate, rule trigger frequency); response time metrics (real-time response time, response time trend, and deviation from historical baseline); and test result evaluation metrics (test case execution success rate, coverage progress, and constraint fulfillment status (e.g., whether the time budget was exceeded). Based on these metrics, dynamic adjustments and operations are performed: if the WAF's CPU utilization is ≥80%, the concurrency is automatically reduced; if network latency suddenly increases, a network quality check is triggered and the test is paused; if a certain type of test case continues to fail, it is automatically replaced with a similar backup test case; if the response time trend is abnormal (e.g., continuously increasing), the test case execution order is adjusted (prioritizing low-load test cases); all adjustments must not violate structured constraints, and major adjustments (e.g., replacing core test cases) must be logged.

[0163] This embodiment achieves intelligent selection of test cases and automation of the testing process, greatly improving testing efficiency and coverage, while ensuring the accuracy of response time data and adapting to dynamic changes during the testing process, thus ensuring the effectiveness and reliability of the test.

[0164] In addition, this application provides an automated testing system for Web application firewall proxy response time, such as... Figure 4 As shown, it includes: test case testing module, test execution module, test result judgment module, test report module, and test result notification module.

[0165] The test case generation module consists of four core sub-modules: a semantic crawling and analysis engine, a user behavior modeler, a threat intelligent injection engine, and a test case evolution and optimizer. These form a closed-loop intelligent test case generation system, with the specific process as follows: Figure 2 As shown, it includes:

[0166] The semantic crawling and analysis engine crawls basic elements such as URLs, parameters, and headers, and identifies page function semantics (such as login, search, payment, file upload, etc.) through static analysis and lightweight dynamic execution.

[0167] The user behavior modeler is designed to build typical user behavior sequence models based on historical access logs or simulated operations.

[0168] The threat intelligence injection engine is designed to dynamically generate attack vectors based on semantic context.

[0169] The use case evolution and optimizer automatically adjusts the combination of use cases and attack intensity based on feedback from multiple rounds of testing, thereby enabling the use cases to evolve adaptively.

[0170] This embodiment introduces four levels: semantic understanding, behavioral modeling, intelligent threat generation, and evolutionary optimization, which can significantly improve the realism, coverage, and adaptability of the test; it is especially suitable for enterprises and cloud environments with high requirements for WAF performance and security detection capabilities.

[0171] The test execution module's execution logic is as follows: Figure 3 As shown, the use case selection adopts a design combining an intelligent recommendation engine and an adaptive execution framework to achieve full-process automation from use case recommendation to dynamic adjustment. The client agent is invoked to simulate sending requests, recording the complete response time. Key statistics are as follows: DNS resolution time, TCP connection establishment time, SSL / TLS handshake time (HTTPS), time from request start to response start, time from request start to receiving the first byte (TTFB), and total time. It includes the following sub-modules:

[0172] The intelligent recommendation engine, acting as the module's decision-making brain, intelligently recommends test case sets and execution order based on testing objectives, WAF configuration, and historical performance data. It also generates multi-objective trade-off solutions for users to choose and adjust. This is achieved through deep reinforcement learning modeling of test case selection and ranking, multi-objective optimization providing non-dominated solutions, extracting WAF-specific features to construct test case feature vectors, and fine-tuning the recommendation results in conjunction with real-time context.

[0173] The multidimensional constraint generator transforms user requirements, system limitations, and test specifications into machine-processable constraints. It dynamically maintains a constraint knowledge base and supports real-time updates based on user adjustments, ensuring the feasibility of test plans in terms of time, resources, and coverage. Technically, it uses CSP formal modeling to define test case-related variables and various constraints, and includes a built-in WAF-specific constraint library adapted to proxy response time testing requirements. It supports dynamic relaxation and replanning based on priority when constraints conflict, and can also parse user natural language or interactive adjustments into corresponding changes to the constraints.

[0174] The dynamic execution scheduler is responsible for translating recommended solutions into specific, flexibly adjustable execution plans. During testing, it monitors the WAF status and response metrics in real time, dynamically adjusting execution pace, concurrency strategies, and even switching test modes to address performance fluctuations and ensure test effectiveness.

[0175] A real-time feedback optimizer continuously collects data such as response time, error rate, and rule triggering during test execution, evaluates test performance online, and provides timely feedback to the recommendation engine and scheduler, enabling continuous optimization and increasing accuracy in the testing process. Technically, it updates recommendation model weight parameters in real time through incremental learning, utilizes statistical process control and causal inference to detect response time anomalies and pinpoint root causes, dynamically adjusts recommendation priorities based on actual test case performance, and also builds a real-time dashboard to visually display key information such as coverage and response time distribution, providing intuitive support for human intervention in decision-making.

[0176] This embodiment achieves a high degree of automation and intelligence in testing WAF agent response time through data-driven intelligent recommendation, refined constraint management, context-aware dynamic scheduling, and closed-loop online learning. It surpasses the simple "fixed script + manual monitoring" mode in existing technologies, significantly improving testing efficiency, accuracy, and scenario adaptability.

[0177] The test decision module is used to perform tests based on the test plan, and specifically includes:

[0178] For each test case, feature vectors are extracted, including URL path structure, number of parameters, request method (GET / POST), Content-Type, and historical response time variance. Clustering algorithms (such as DBSCAN or hierarchical clustering) are used to group test cases with similar features into the same "request behavior cluster." Requests within a cluster typically trigger similar WAF rule sets, potentially leading to resource contention or caching interference. Strategies are automatically generated: Intra-cluster strategy: If request features within a cluster are highly similar and WAF rule sets have high overlap, sequential execution is automatically recommended to avoid concurrency interference causing response time distortion. Inter-cluster strategy: If there are significant differences in features between different clusters, parallel or combined execution is recommended to simulate real mixed traffic scenarios. Special strategy: For resource-intensive test cases including file uploads and large request bodies, isolation execution markers are automatically inserted. User interaction is simplified, providing "performance load testing preference" and "precision priority" sliders. The system dynamically adjusts the clustering threshold and concurrency limit based on the slider position, eliminating the need for users to understand the underlying technical details.

[0179] The test logs for reading the web application firewall by calling the client agent have the following parameters: request_time: total client request time (from receiving the first byte to sending the last byte), upstream_connect_time: time to establish a connection with the upstream server (if it is a new connection), upstream_header_time: time from connecting to the upstream server to receiving the response header (including connection time), and upstream_response_time: time from connecting to the upstream server to receiving the response body (including connection time).

[0180] Based on the client request time (T_client_raw) of the test execution module and the request time (request_time) of the web application firewall, a multi-source timestamp alignment and network latency compensation algorithm is established. The error is calibrated through the following steps: First, clock synchronization is performed before the test. The client agent and the WAF server synchronize their time via the NTP protocol, and the synchronization deviation Δsync (usually <1ms) is recorded. If Δsync > 5ms, synchronization is automatically retried or the test round is marked as a high-deviation state. Second, before and during the formal test, lightweight ICMP probe packets or empty HTTP HEAD requests are periodically sent to measure the average network round-trip time (RTT_net) from the client to the WAF. The sliding median of the last 5 measurements is taken as the current network latency estimate. Then, timestamp collection and preprocessing are performed. The client records the request sending time T_send (taken from the operating system's high-precision timer) and the complete reception time of the response T_recv, calculating the raw client time: T_client_raw = T_recv - T_send. The request_time is extracted from the WAF log and recorded as T_waf_total (precision is usually milliseconds or microseconds). Furthermore, network latency compensation is performed. The client latency includes the one-way network transmission time from the client to the WAF, theoretically RTT_net / 2. The compensated client latency is calculated as: T_client_compensated = T_client_raw - RTT_net / 2. Additionally, if the test period is long, a linear clock drift model is introduced. Several baseline requests (with known expected response times) are inserted into the test sequence. The real-time clock drift factor ρ is calculated using the ratio of the actual latency to the expected latency of the baseline requests. This is then used to further correct the compensated client latency, i.e., T_client_calibrated = T_client_compensated / ρ. Next, the absolute difference between the client-side time and the WAF log time after calibration is calculated: Δ = |T_client_calibrated - T_waf_total|. If Δ ≤ 0.1 × T_waf_total, the measurement is considered valid, and the data is included in subsequent analysis. If the relative error exceeds 10%, the system automatically performs the following actions: immediately retry the test case, up to 3 times, record the exception log and trigger a network quality check; if 5 consecutive test cases are invalid, the test is paused and an alarm is issued. Finally, the same test case is tested multiple times (3 times by default). After removing abnormal samples with a relative error exceeding 10%, the median or truncated mean is taken as the final measurement result to further improve data robustness.

[0181] The response time of the web application firewall proxy is obtained by subtracting upstream_response_time from the request_time data.

[0182] The test report module is implemented using a multi-dimensional statistical analysis engine based on adaptive performance modeling. This engine no longer simply outputs the mean and maximum values, but dynamically selects the optimal statistical model based on the data distribution characteristics. It provides a series of performance indicators with statistical significance, robustness, and predictive power, making the evaluation of WAF agent response time more scientific and reliable. Specifically, it includes:

[0183] It automatically identifies and handles outliers (such as extreme values ​​caused by network jitter or system scheduling delays), adopts an outlier detection algorithm based on median absolute deviation (MAD), and outputs robust statistics such as truncated mean, weighted median, and interquartile range to avoid individual outliers distorting the overall evaluation.

[0184] Calculate the sample median M and the absolute deviation sequence |x_i-M|, and take the median to obtain MAD; mark observations with |x_i-M|>3*MAD as outliers, which can be removed or imputed with the median; output the truncated mean (mean after removing the top and bottom 5% extreme values), weighted median (weighted according to response time), etc.

[0185] Response time distribution modeling and goodness-of-fit evaluation: For response time samples of each test dimension (e.g., URL, attack type, concurrency level), it automatically fits multiple probability distributions (normal, log-normal, Weibull, gamma, etc.), selects the best-fit distribution using the KS test or AIC / BIC criterion, and outputs distribution parameters, probability density function curves, and specified quantiles (50th / 90th / 95th / 99th). This function can reveal the true distribution pattern of response time—for example, if the data has a long-tailed distribution, the 99th quantile is more valuable than the mean. It uses maximum likelihood estimation (MLE) to fit candidate distributions; calculates the KS statistic or AIC / AICc / BIC values, selects the distribution corresponding to the minimum information criterion; outputs the distribution name, parameter estimates, and calculates arbitrary quantiles using the inverse distribution function.

[0186] Confidence Intervals and Statistical Significance Assessment: Bootstrap resampling technology (no distribution assumption required) is used to generate 95% confidence intervals for key indicators such as mean, median, and quantiles. The system automatically performs two-sample hypothesis testing (Mann-Whitney U test or Welch t test) on the current test results and historical baselines, outputting a conclusion on whether the performance change is statistically significant (p-value and effect size). Bootstrap Method: The original sample is resampled 1000 times with replacement. The target statistic is calculated each time, and the 2.5% and 97.5% quantiles are used as the 95% confidence intervals. Historical Comparison: The Mann-Whitney U rank-sum test (non-parametric, normality not required) is used to calculate the U statistic and p-value. If p < 0.05, the performance change is considered significant.

[0187] Performance stability and consistency metrics: Calculate the coefficient of variation (CV), relative standard deviation, and time-series autocorrelation coefficient to quantify the degree of response time fluctuation of the WAF when handling similar requests. For long-term test series, output moving average trend lines and seasonal decomposition components to help identify performance degradation or periodic fluctuations. Calculate simple moving average (SMA) or exponentially weighted moving average (EWMA) for time series samples; use CUSUM control charts to detect whether the mean has drifted; the coefficient of variation formula is CV = standard deviation / mean, and a CV > 0.3 indicates significant performance fluctuation.

[0188] Multidimensional feature aggregation and performance heatmaps: Supports dynamic grouping by use case attributes (such as attack payload length, WAF rule ID, URL path depth), automatically generating two-dimensional performance heatmaps to intuitively present the differences in response time distribution under different feature combinations, helping to quickly locate performance bottlenecks. Based on Pandas' groupby mechanism, it groups users by one or more categorical variables (such as attack type, rule ID); it automatically executes all the above statistical processes for each group, generating a structured performance report, which can be rendered as a heatmap (Matplotlib / Plotly).

[0189] Customizable statistical indicator script engine: Provides a lightweight script interface that allows users to define any statistical function (e.g., timeout ratio, response time slope, resource consumption ratio). The system automatically executes and outputs the results during the data aggregation stage, meeting the needs of deep customization.

[0190] The test result notification module is used to notify test results via email or by directly writing them into a standard test report in a fixed format.

[0191] This application's embodiment consists of five major modules: test case generation, test execution, result judgment, reporting, and notification. These modules work together to achieve intelligent test case generation, automated test execution, accurate data calibration calculation, scientific and professional evaluation, and multi-format result output. This realizes automation, intelligence, and precision in the entire testing process, eliminating the inefficiency of traditional manual testing, realistically reproducing business and attack scenarios, and improving the accuracy of test results.

[0192] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make modifications, alterations, substitutions and variations to the above embodiments within the scope of this application.< / form>

Claims

1. An automated testing method for Web application firewall proxy response time, characterized in that, include: Based on the access address of the page under test, extract all basic elements of the page under test, and perform NLP semantic intent recognition on each basic element to obtain the business semantic function corresponding to each basic element. Based on each basic element and the corresponding business semantic function, multiple effective functional paths are constructed. The effective functional path is an ordered sequence of multiple basic elements with continuous business semantic functions, arranged in the order of business semantic functions. Each effective functional path is input into a pre-configured user behavior sequence model to quantify the jump probability between different effective functional paths. Based on the jump probability between different effective functional paths and the pre-configured high-frequency scenario business template, at least one typical user behavior chain is constructed, wherein the typical user behavior chain includes at least one effective functional path. Based on all the basic elements and corresponding business semantic functions in each typical user behavior chain, an attack vector set corresponding to each typical user behavior chain is generated, and each attack vector set is injected into the corresponding typical user behavior chain to generate a test case set. The page under test is tested based on the test case set to obtain the response time test results of the page under test.

2. The automatic testing method for Web application firewall proxy response time according to claim 1, characterized in that, Based on the access URL of the page under test, extract all basic elements of the page under test, including: Based on the access address of the page under test, the static structure of the page under test is traversed through the DOM parsing algorithm to extract all static structural elements on the page under test. Then, the page under test is dynamically rendered based on a pre-set headless browser to extract all dynamic structural elements on the page under test. Each of the basic elements is either a static structural element or a dynamic structural element, and each static structural element and each dynamic structural element includes a corresponding URL identifier.

3. The automatic testing method for Web application firewall proxy response time according to claim 2, characterized in that, Perform NLP semantic intent recognition on each basic element to obtain the corresponding business semantic function, including: Based on the URL identifier corresponding to each of the static structural elements and each of the dynamic structural elements, the content element corresponding to each URL identifier is extracted, wherein the content element includes page text, button labels or form prompts. Perform NLP semantic intent recognition on each of the content elements to obtain the business semantic function corresponding to each URL identifier.

4. The automatic testing method for Web application firewall proxy response time according to claim 1, characterized in that, Based on each basic element and its corresponding business semantic function, multiple effective functional paths are constructed, including: Based on the business semantic function corresponding to each basic element, each basic element is filtered to eliminate basic elements whose business semantic function has no practical meaning. Based on the business semantic functions corresponding to the filtered basic elements, the logical relationships between different basic elements are confirmed. Based on the logical connections between different basic elements, multiple effective functional paths are constructed.

5. The automatic testing method for Web application firewall proxy response time according to claim 1, characterized in that, Based on all the basic elements and corresponding business semantic functions in each typical user behavior chain, an attack vector set is generated for each typical user behavior chain, including: Based on all the basic elements and corresponding business semantic functions in each typical user behavior chain, as well as the pre-set abstract syntax tree algorithm, the parameter type and data structure corresponding to each basic element in each typical user behavior chain are obtained. Based on the business semantic function corresponding to each basic element in each typical user behavior chain, and the pre-set threat model invocation strategy, obtain at least one threat model corresponding to each typical user behavior chain. Based on at least one threat model corresponding to each typical user behavior chain, and the parameter type and data structure corresponding to each basic element in each typical user behavior chain, an attack vector set corresponding to each typical user behavior chain is created, wherein the attack vector set includes multiple attack payload variants.

6. The automatic testing method for Web application firewall proxy response time according to claim 5, characterized in that, Each attack vector set is injected into the corresponding typical user behavior chain to generate a test case set, including: Each attack vector set is injected into the corresponding typical user behavior chain, and a test case set is generated based on a pre-set test case generation strategy. The test case generation strategy is used to generate baseline test cases without attack payload variant injection, attack test cases with full-link injection attack payload variants, and hybrid test cases with partial-step injection attack payload variants. The generated test cases are tested and iteratively optimized until the pre-set optimization goal or iteration limit is reached.

7. The automatic testing method for Web application firewall proxy response time according to any one of claims 1 to 6, characterized in that, The page under test is tested based on the test case set to obtain the response time test results of the page under test, including: Feature extraction and vectorization are performed on the test case set, pre-set test objectives, WAF configuration information and historical performance data to obtain WAF test case feature vectors; The WAF test case feature vector is input into a pre-trained reinforcement learning model to obtain multiple test case recommendation schemes. The reinforcement learning model is used to model the test case selection and ranking problem as a Markov decision process and solve the Markov decision process to generate multiple test case recommendation schemes. The system visualizes the recommended solutions for multiple use cases and generates the final execution plan based on the received user feedback. Based on the final execution plan, the pre-set test environment, and structured constraints, the page under test is tested to obtain the response time test results.

8. The automatic testing method for Web application firewall proxy response time according to claim 7, characterized in that, Based on the final execution plan, a pre-set test environment, and structured constraints, the page under test is tested to obtain response time test results, including: Based on the final execution plan, the pre-set test environment, and the structured constraints, simulate sending HTTP / HTTPS requests to the page under test; During the sending of HTTP / HTTPS requests, client timestamp data and WAF log data are obtained in real time; The client timestamp data and WAF log data are calibrated based on a pre-set network latency compensation algorithm and clock synchronization strategy, and the WAF proxy response time is calculated based on the calibrated WAF log data.

9. The automatic testing method for Web application firewall proxy response time according to claim 8, characterized in that, The method further includes the following steps during the sending of HTTP / HTTPS requests: The system acquires WAF status data, response time metrics, and test result evaluation metrics in real time, and adjusts the test environment and final execution plan in real time based on the WAF status data, response time metrics, and test result evaluation metrics.

10. The automatic testing method for Web application firewall proxy response time according to claim 1, characterized in that, After obtaining the response time test results of the page under test, the method further includes: The response time test results of the tested page are post-processed, and a corresponding test result report is generated based on the post-processing results; The test result report is processed for notification based on a pre-set notification strategy.

Images