Flow testing method and device, electronic equipment and computer program product

Abstract

The invention discloses a flow testing method and device, electronic equipment and a computer program product. Relates to the field of financial science and technology, and the method comprises the steps: collecting network flow data generated by a to-be-detected system in a network communication process, carrying out the feature analysis of the network flow data, and obtaining network flow features; the network flow characteristics are input into a request recognition model and processed to obtain a network analysis result of the network flow data, the network flow characteristics are input into a field recognition model and processed to obtain a field recognition result, and the request recognition model is used for recognizing the relation between different requests in the network flow data based on the network flow characteristics; the field identification model is used for positioning and identifying fields in the network traffic data; and constructing a test case according to the network analysis result and the field identification result, and executing the test case. Through the test case generation method and device, the technical problem that the accuracy of test case generation is low in the face of dynamically changing business logic under a micro-service architecture in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to a method, apparatus, electronic device, and computer program product for testing traffic. Background Technology

[0002] With the increasing complexity of internet applications, especially the widespread adoption of microservice architectures, security testing of software systems faces unprecedented challenges. Traditional security testing methods typically rely on the experience of security experts to design test cases for specific functions or interfaces in order to discover potential security vulnerabilities.

[0003] However, in dynamic, interconnected service environments, especially when dealing with rapidly evolving business logic and technological changes, this testing strategy based on personal experience and static test cases has gradually revealed its limitations. Manually written test cases and vulnerability verification programs often focus on individual network requests, failing to fully consider the coherence of business logic and contextual dependencies. In microservice architectures, frequent interface changes and parameter adjustments require test cases to keep pace, but traditional methods relying on human intervention struggle to respond to these changes in real time. This causes security measures to lag behind system development, increasing potential security risks.

[0004] Furthermore, most existing security testing tools and frameworks adopt an isolated vulnerability scanning mode, that is, checking the vulnerability of each interface or function point one by one, while ignoring the integrity and sequence of business processes. For example, in the CAPTCHA mechanism, from generation and transmission to verification, a series of interdependent requests and responses are involved. Traditional tools only focus on the vulnerability of a certain link and fail to form a complete security verification chain.

[0005] Furthermore, when faced with complex scenarios such as distributed transactions and user session management, test cases lack the ability to deeply analyze the business logic context, making it difficult to effectively identify and verify the validity of session tokens, the dependencies between parameters, and their inherent logic, thus failing to comprehensively assess the security of the system.

[0006] There is currently no effective solution to the technical problem of low accuracy in generating test cases when dealing with dynamically changing business logic in a microservice architecture. Summary of the Invention

[0007] The main purpose of this application is to provide a traffic testing method, device, electronic device, and computer program product to solve the technical problem of low accuracy in generating test cases when facing dynamically changing business logic in a microservice architecture.

[0008] To achieve the above objectives, according to one aspect of this application, a traffic testing method is provided. The method includes: collecting network traffic data generated by the system under test during network communication; performing feature analysis on the network traffic data to obtain network traffic features; inputting the network traffic features into a request identification model to obtain network analysis results of the network traffic data; inputting the network traffic features into a field identification model to obtain field identification results, wherein the request identification model is used to identify the relationship between different requests in the network traffic data based on the network traffic features; the network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in the network traffic data; the field identification model is used to locate and identify fields in the network traffic data; and the field identification results refer to the identification results of whether a field in the network traffic data is a preset field; constructing test cases based on the network analysis results and the field identification results, and executing the test cases, wherein the test cases are used to test the system under test.

[0009] Furthermore, the network traffic characteristics are input into the request identification model, and the network analysis results obtained from the network traffic data include: extracting the time nodes and request parameters of M requests associated with the network traffic data from the network traffic characteristics, resulting in M ​​time nodes and M sets of request parameters, where M is a positive integer; determining whether the M requests are continuous based on the M time nodes and M sets of request parameters; if N requests are continuous among the M requests, generating a continuous request sequence based on the N requests, where N is less than or equal to M and N is a positive integer; generating a non-continuous request sequence based on the M requests; and generating network analysis results based on the continuous request sequence and the non-continuous request sequence.

[0010] Furthermore, the network traffic features are input into the field recognition model, and the resulting field recognition is processed as follows: the attention layer of the field recognition model identifies Y fields in the network traffic features to obtain Y field weights, where Y is a positive integer; a weight threshold is obtained, and if K field weights among the Y field weights are greater than or equal to the weight threshold, a field recognition result is generated based on the fields corresponding to the K field weights, where K is less than or equal to Y and K is a positive integer.

[0011] Furthermore, constructing test cases based on network analysis results and field identification results includes: determining the request sequence types of the K fields associated with the field identification results based on the network analysis results, wherein the request sequence types include continuous request sequence types and non-continuous request sequence types; if the request sequence types of the K fields are continuous request sequence types, obtaining the vulnerability patterns corresponding to the K fields, obtaining a first policy template based on the K vulnerability patterns, wherein the vulnerability patterns include at least: improper cross-origin resource configuration, lack of cross-site request protection, and unauthorized access; obtaining the request environment of the request sequence to which the K fields belong, obtaining a first request environment; filling the parameters of the first policy template according to the first request environment to obtain a first test case policy, and constructing test cases based on the first test case policy.

[0012] Furthermore, after determining the request sequence types of the K fields associated with the field identification results based on the network analysis results, the method further includes: when the request sequence types of the K fields are non-continuous request sequence types, selecting a second strategy template from the first strategy template based on the K vulnerability patterns; obtaining the request environment of the request sequence to which the K fields belong, obtaining a second request environment, filling parameters into the second strategy template based on the second request environment, obtaining a second test case strategy; and constructing test cases based on the second test case strategy.

[0013] Furthermore, constructing test cases based on network analysis results and field identification results includes: obtaining a test case strategy determined based on network analysis results and field identification results, wherein the test case strategy includes a first test case strategy and a second test case strategy; transforming the test case strategy to obtain a structured test script, and generating test cases based on the structured test script.

[0014] Furthermore, executing test cases includes: loading the structured test script associated with the test case and executing the test case according to the test environment configuration parameters; while executing the test case, collecting the execution status and response data of the test case, and obtaining the test results after the test case is completed; generating a test report based on the execution status, response data, and test results, and sending the test report to the client.

[0015] To achieve the above objectives, according to another aspect of this application, a traffic testing system is provided. The system includes: a traffic acquisition layer, used to acquire network traffic data generated by the system under test during network communication, perform feature analysis on the network traffic data to obtain network traffic features; a feature analysis engine, including a request recognition model and a field recognition model, used to input network traffic features into the request recognition model, process to obtain network analysis results of the network traffic data, and input network traffic features into the field recognition model, process to obtain field recognition results; a decision center, used to construct test case strategies based on the network analysis results and field recognition results; a test case generator, used to structurally transform the test case strategies to obtain structured test scripts, and generate test cases based on the structured test scripts; and a test execution module, used to execute test cases, generate test reports, and send the test reports to the client.

[0016] To achieve the above objectives, according to another aspect of this application, a traffic testing apparatus is provided. The apparatus includes: a data acquisition unit for acquiring network traffic data generated by the system under test during network communication, performing feature analysis on the network traffic data to obtain network traffic features; an input unit for inputting the network traffic features into a request identification model to obtain network analysis results of the network traffic data, and inputting the network traffic features into a field identification model to obtain field identification results, wherein the request identification model is used to identify the relationship between different requests in the network traffic data based on the network traffic features, the network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in the network traffic data, the field identification model is used to locate and identify fields in the network traffic data, and the field identification result refers to the identification result of whether a field in the network traffic data is a preset field; and a first construction unit for constructing test cases based on the network analysis results and the field identification results, and executing the test cases, wherein the test cases are used to test the system under test.

[0017] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the test method for any of the above-mentioned traffic.

[0018] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory storing an executable program, and the processor for running the program, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any of the above-described methods for testing traffic.

[0019] According to another aspect of the present invention, a computer program product is also provided, the computer program product including a computer program, wherein the computer program, when executed by a processor, implements the above-described method for testing traffic.

[0020] In this embodiment, a traffic testing method is used. Network traffic data generated by the system under test during network communication is collected, and feature analysis is performed on the network traffic data to obtain network traffic features. These network traffic features are then input into a request identification model to obtain network analysis results. Finally, the network traffic features are input into a field identification model to obtain field identification results. The request identification model is used to identify the relationships between different requests in the network traffic data based on the network traffic features. The network analysis results indicate the correlation and temporal sequence analysis results between different requests in the network traffic data. The field identification model is used to locate and identify fields in the network traffic data. The field identification results refer to the network... The system identifies whether the fields in network traffic data are the results of preset field recognition; it constructs and executes test cases based on network analysis results and field recognition results. These test cases are used to test the system under test. This solves the technical problem of low accuracy in generating test cases when facing dynamically changing business logic in a microservice architecture. By performing feature analysis on network traffic data, network traffic features are obtained. These network traffic features are then input into the request recognition model and the field recognition model, respectively. Test cases are constructed and executed based on the network analysis results and field recognition results output by the models. This improves the accuracy of generated test cases, thereby enhancing the accuracy and efficiency of vulnerability detection. Attached Figure Description

[0021] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) used to implement a method for testing traffic.

[0023] Figure 2 This is a flowchart of a traffic testing method provided according to an embodiment of this application;

[0024] Figure 3 This is a schematic diagram of a traffic testing system provided according to an embodiment of this application;

[0025] Figure 4 This is a schematic diagram of a flow rate testing device provided according to an embodiment of this application;

[0026] Figure 5This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties. For example, this system has interfaces with relevant users or organizations to provide users with corresponding operation data for them to choose to agree to or refuse automated decision results. Before obtaining relevant information, a request for obtaining the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained after receiving consent from the aforementioned user or organization; if the user chooses to refuse, the expert decision-making process is initiated. Users can view the purpose of data use in real time through authorization decoding and have the right to withdraw authorization or delete data at any time. After the authorization is withdrawn, the system will terminate the relevant data processing within 24 hours.

[0030] It should be noted that the information collected in this application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize use or refuse use.

[0031] Example 1

[0032] According to an embodiment of this application, a method embodiment for testing traffic flow is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) used to implement a method for testing traffic flow, such as... Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 (Illustrated as 102a, 102b, ..., 102n) Processor 102 (processor 102 may include, but is not limited to, a microprocessor MCU (Microcontroller Unit) or a programmable gate array (FPGA), etc.), memory 104 for storing data, and transmission device 106 for communication functions. In addition, it may include: a display, input / output interface (I / O interface), Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), network interface, keyboard, cursor control device, power supply and / or camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0034] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0035] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the traffic testing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned traffic testing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0036] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network interface controller (NIC) and a network interface, which can be connected to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0037] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0038] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for testing traffic flow is shown. Figure 2 This is a flowchart of a traffic testing method provided according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0039] Step S201: Collect network traffic data generated by the system under test during network communication, perform feature analysis on the network traffic data, and obtain network traffic features.

[0040] It should be noted that the system to be tested refers to the software system, network application, or service that needs to be security tested. This can be a system that adopts a microservice architecture, has dynamically changing interface parameters, and complex business logic. Network traffic data refers to the data packets exchanged by the system during communication with the outside world. This can include HTTP (Hypertext Transfer Protocol) / HTTPS (Hypertext Transfer Protocol Secure) requests and responses, data packet header information, message body content, status codes, response times, etc. These data packets carry the system's input and output information during runtime.

[0041] Since real-time traffic data can reflect interface changes, parameter adjustments, and business logic execution within a system, the security testing of the system under test is first conducted by capturing interaction information between the system and users, other services, or other systems using network monitoring tools—that is, obtaining network traffic data. Then, the captured traffic data is preprocessed, such as removing useless metadata, decoding encrypted request bodies, and standardizing timestamps, to ensure the accuracy of the parsing process. Next, key feature information is extracted and parsed from the collected network traffic data to obtain network traffic features. These features can include time-series features, protocol features, and features related to business parameters. Time-series features, by analyzing the time series data of network traffic, can identify the changing trends of traffic patterns over time. Protocol features, based on different network protocols, help identify traffic types and sources, providing a basis for network security protection. Features related to business parameters can analyze the business parameters in the traffic and their interrelationships, helping to understand the specific business logic behind the traffic.

[0042] Step S202: Input network traffic features into the request identification model to obtain network analysis results of network traffic data; input network traffic features into the field identification model to obtain field identification results. The request identification model is used to identify the relationship between different requests in network traffic data based on network traffic features; the network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in network traffic data; the field identification model is used to locate and identify fields in network traffic data; and the field identification results refer to the identification results of whether the fields in network traffic data are preset fields.

[0043] Specifically, the request identification model can be constructed using a Long Short-Term Memory (LSTM) network. By learning patterns from historical traffic data, it can analyze and understand the inherent relationships between different requests within network traffic characteristics, thereby identifying the correlation and temporal sequence of requests and distinguishing which consecutive requests represent normal business processes and which may contain security risks. After obtaining the network traffic characteristics, these characteristics can be input into the request identification model, which then identifies these characteristics and outputs network analysis results of the network traffic data. This lays the foundation for identifying business logic vulnerabilities (such as unauthorized access in consecutive requests) or temporal vulnerabilities (such as CSRF (Cross-Site Request Forgery) and vulnerabilities in CAPTCHA mechanisms).

[0044] Furthermore, while processing using the request identification model, network traffic characteristics can also be input into the field identification model. The model then locates and identifies key fields in the network traffic and outputs the identification results of whether the fields belong to preset sensitive fields, such as unverified CORS (Cross-Origin Resource Sharing) fields, abnormal Referer fields in CSRF (Cross-Site Request Forgery), and UID (Unique Identifier) ​​fields in unauthorized access. The model's analysis distinguishes normal fields from abnormal fields that may cause security problems. The field identification model is based on an attention mechanism network that evaluates the importance of each field and determines whether the field belongs to a preset high-risk category. For example, the model can identify whether there are abnormal links in the Referer field or whether the session token is carried in an inappropriate request.

[0045] Furthermore, more precise test cases can be generated based on the above results, thus forming a complete security testing process from data collection and feature parsing to intelligent analysis and decision-making.

[0046] Step S203: Construct test cases based on network analysis results and field identification results, and execute the test cases, wherein the test cases are used to test the system to be detected.

[0047] Specifically, after obtaining the network analysis results and field identification results from the two models, test scripts or scenarios for verifying specific security risks can be constructed based on these results. These test cases contain specific test objectives, test steps, input data, and expected output results. They are used to simulate the strategies that attackers might employ and verify the system's ability to protect against these security risks. For example, if the network analysis results reveal a sequence of unauthorized access issues in a series of consecutive requests, test cases could include simulating scenarios where users without proper authentication attempt to access restricted resources. If the field identification results indicate that the Origin field in the request header is set to a wildcard, test cases could simulate attempts at cross-domain resource sharing to verify whether the system can correctly identify and block such requests.

[0048] Finally, the constructed test cases are sent to the test execution module for execution. Based on the preset test environment configuration, the execution of each test case is triggered, and the execution status and response data are monitored in real time to simulate various security threat scenarios and verify the effectiveness of the protection mechanisms of the system under test. After the test execution is completed, the raw test results (including pass rate, error logs, system response, etc.) are structured and stored to provide data support for subsequent model iterations and strategy optimization, ensuring the continuous evolution and optimization of system security protection.

[0049] The traffic testing method provided in this application collects network traffic data generated by the system under test during network communication, performs feature analysis on the network traffic data to obtain network traffic features, inputs the network traffic features into a request identification model to obtain network analysis results of the network traffic data, and inputs the network traffic features into a field identification model to obtain field identification results. The request identification model is used to identify the relationship between different requests in the network traffic data based on the network traffic features; the network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in the network traffic data; and the field identification model is used to locate and identify fields in the network traffic data. The field identification results refer to the network traffic... The system identifies whether the fields in the data are the preset fields; it constructs and executes test cases based on network analysis results and field identification results. These test cases are used to test the system under test. This solves the technical problem of low accuracy in generating test cases when facing dynamically changing business logic in a microservice architecture. By performing feature analysis on network traffic data, network traffic features are obtained. These network traffic features are then input into the request identification model and the field identification model, respectively. Test cases are constructed and executed based on the network analysis results and field identification results output by the models. This improves the accuracy of generated test cases, thereby enhancing the accuracy and efficiency of vulnerability detection.

[0050] Optionally, in the traffic testing method provided in this application embodiment, inputting network traffic features into a request identification model and processing the network traffic data to obtain network analysis results includes: extracting the time nodes and request parameters of M requests associated with the network traffic data from the network traffic features to obtain M time nodes and M sets of request parameters, where M is a positive integer; determining whether the M requests are continuous based on the M time nodes and M sets of request parameters; if N requests are continuous among the M requests, generating a continuous request sequence based on the N requests, where N is less than or equal to M and N is a positive integer; generating a non-continuous request sequence based on the M requests; and generating network analysis results based on the continuous request sequence and the non-continuous request sequence.

[0051] Specifically, when analyzing the request identification model, since each request has an associated time node (i.e. the time when the request was sent) and a set of request parameters (including request path, method type, header information, message body, etc.), it is necessary to extract the time sequence and specific content of all related requests from the network traffic to obtain multiple time nodes and request parameters.

[0052] Furthermore, to identify requests that may follow specific business processes and to check for abnormal continuous request patterns, such as continuous operations that bypass normal business logic, thereby identifying security vulnerabilities such as unauthorized or unauthorized access, requests can be sorted and time differences calculated based on time nodes to determine the relative time intervals between these requests. When requests are closely linked in chronological order, i.e., the next request is sent immediately after the previous request is completed, or a preset time interval threshold is met, the requests are considered continuous. In this case, continuous request sequences can be constructed based on continuous requests, and non-continuous request sequences can be generated from non-continuous requests. The temporal dependencies between them can be analyzed to more accurately understand and predict network traffic behavior patterns. Finally, network analysis results are generated based on continuous and non-continuous request sequences, providing strong support for real-time monitoring and anomaly detection.

[0053] This embodiment accurately identifies patterns of continuous and discontinuous requests from complex network traffic, thereby deeply analyzing the coherence and security of business processes. It can detect and prevent business logic-based attacks earlier, thus strengthening system security at the source, improving overall system security and user experience, and also increasing the efficiency of security testing.

[0054] Optionally, in the traffic testing method provided in this application embodiment, inputting network traffic features into a field recognition model and processing to obtain field recognition results includes: identifying Y fields in the network traffic features by the attention layer of the field recognition model to obtain Y field weights, where Y is a positive integer; obtaining a weight threshold; if there are K field weights among the Y field weights that are greater than or equal to the weight threshold, generating field recognition results based on the fields corresponding to the K field weights, where K is less than or equal to Y and K is a positive integer.

[0055] Specifically, when using the field recognition model for processing, high-risk fields can be located based on the attention mechanism. That is, the attention layer integrated into the field recognition model is used for recognition, thereby assessing the importance of each field in the network traffic characteristics, so as to better identify high-risk fields and improve the accuracy and efficiency of vulnerability detection. Among them, the attention mechanism is an effective feature weighting technique that can highlight key information and ignore irrelevant information.

[0056] When the model receives network traffic features as input, the attention layer can analyze each field based on its location, type, content, and correlation with known security risks within the request. After processing by the attention layer, each field obtains a quantified value, i.e., a corresponding field weight. This weight represents the relative importance or risk level of the field in network traffic analysis, reflecting the field's contribution to identifying potential security threats. This effectively filters out the fields in network traffic features most relevant to security testing, avoiding unnecessary analysis of low-risk fields and improving the efficiency and accuracy of security vulnerability detection.

[0057] Furthermore, after calculating the field weights, these field weights can be iterated through to find all fields that are greater than or equal to the weight threshold. These fields are then identified as high-risk fields, and field identification results are generated based on them to indicate which fields' existence or usage may cause security issues, such as anomalies in the Referer field in CSRF or improper settings in the Origin field in CORS.

[0058] This embodiment integrates attention mechanisms and weight threshold judgments, enabling the field recognition model to intelligently filter out the most noteworthy fields in network traffic. The generated field recognition results provide precise targets for subsequent security testing, which not only improves the efficiency of security testing but also enhances its quality and reliability.

[0059] Optionally, in the traffic testing method provided in this application embodiment, constructing test cases based on network analysis results and field identification results includes: determining the request sequence type to which K fields associated with the field identification results belong based on the network analysis results, wherein the request sequence type includes continuous request sequence type and non-continuous request sequence type; when the request sequence type to which the K fields belong is a continuous request sequence type, obtaining the vulnerability pattern corresponding to the K fields, obtaining a first policy template based on the K vulnerability patterns, wherein the vulnerability patterns include at least: improper cross-origin resource configuration, lack of cross-site request protection, and unauthorized access; obtaining the request environment of the request sequence to which the K fields belong, obtaining a first request environment; filling parameters into the first policy template based on the first request environment to obtain a first test case policy, and constructing test cases based on the first test case policy.

[0060] Specifically, when generating test cases, since continuous requests follow specific business processes, it is easy to cause more complex security problems, such as unauthorized access. At this time, it is necessary to determine the request sequence type to which the fields associated with the field identification results belong based on the network analysis results, that is, to identify whether the request sequence to which these fields belong is continuous or non-continuous.

[0061] If a field appears in a continuous request sequence type, i.e., a request sequence issued according to the expected order of the business process, the corresponding strategy template can be determined based on the continuous request sequence type. This requires obtaining the field's position and context within the continuous request sequence to identify the corresponding vulnerability patterns. For example, if the field identification results involve an abnormal weight of the `Origin` field, the vulnerability pattern could be cross-origin resource misconfiguration. Here, vulnerability pattern refers to a predefined security vulnerability type, which may include cross-origin resource misconfiguration, lack of cross-site request protection, etc. Then, based on the vulnerability pattern, a first strategy template is determined to guide the construction of test cases. Next, a first test case strategy is constructed based on the first request environment, i.e., parameters are populated into the first strategy template according to the first request environment to obtain the first test case strategy. The request environment can be user identity, the response result of the previous request in the request sequence, etc. Finally, test cases targeting specific security risks in the continuous request sequence type are generated based on the first test case strategy.

[0062] This embodiment generates test cases with business logic and request environment context for high-risk fields in a continuous request sequence, which significantly improves the accuracy and effectiveness of security testing. It can not only comprehensively cover various typical security vulnerabilities, but also respond to changes in system architecture and business processes in a timely manner by dynamically adjusting the test strategy, thus ensuring the continuous optimization and adaptability of security testing.

[0063] Optionally, in the traffic testing method provided in this application embodiment, after determining the request sequence type to which the K fields associated with the field identification result belong based on the network analysis result, the method further includes: if the request sequence type to which the K fields belong is a non-continuous request sequence type, selecting a second strategy template from the first strategy template based on the K vulnerability patterns; obtaining the request environment of the request sequence to which the K fields belong to obtain a second request environment; filling parameters into the second strategy template based on the second request environment to obtain a second test case strategy; and constructing test cases based on the second test case strategy.

[0064] Specifically, if the request sequence type associated with the field identification result is determined to be a non-continuous request sequence type based on the network analysis results, then the vulnerability pattern identified can be used to filter out a second strategy template based on the position and context of the field in the continuous request sequence, so as to build more accurate test cases and ensure comprehensive coverage of security risks in non-continuous scenarios.

[0065] Furthermore, the parameters of the second policy template are dynamically adjusted based on the specific context of the request, i.e., based on the second request environment, to obtain the second test case policy. This ensures that the test cases accurately reflect the actual scenario of discontinuous requests, improving the practicality and accuracy of security testing. Finally, test cases are constructed based on the second test case policy. For example, the effectiveness of the CORS policy can be tested by constructing requests with an abnormal Origin field, or requests without a Referer field can be simulated to detect CSRF protection mechanisms.

[0066] This embodiment generates and executes targeted test cases for high-risk fields and vulnerability patterns in non-continuous request sequence types, ensuring comprehensive and accurate detection of security vulnerabilities in non-continuous request scenarios. It can effectively supplement security testing for continuous request sequence types, improve the overall security testing quality and efficiency, and provide strong support for timely discovery and remediation of potential security risks.

[0067] Optionally, in the traffic testing method provided in this application embodiment, constructing test cases based on network analysis results and field identification results includes: obtaining a test case strategy determined based on network analysis results and field identification results, wherein the test case strategy includes a first test case strategy and a second test case strategy; performing structural transformation on the test case strategy to obtain a structured test script, and generating test cases based on the structured test script.

[0068] Specifically, after obtaining multiple test case strategies, the first step is to structurally transform these strategies, converting the descriptive information into computer-executable scripts. This allows the strategies to be directly understood and executed by automated test execution units, improving the automation level and efficiency of security testing. Furthermore, parameters can be populated based on request environment information (such as the first and second request environments) to ensure the test scripts accurately reflect the actual test scenarios, improving the accuracy and reliability of the tests.

[0069] Furthermore, specific test cases are generated based on structured test scripts. Each test case can include information such as test scripts, expected results, and test environment configurations.

[0070] This embodiment generates a first test case strategy and a second test case strategy from network analysis results and field identification results, and transforms them into structured test scripts to ultimately generate executable test cases. This not only improves the automation level of security testing and reduces the burden of manually writing test cases, but also ensures the comprehensiveness and accuracy of testing, effectively covering potential security vulnerabilities under continuous and non-continuous requests.

[0071] Optionally, in the traffic testing method provided in this application embodiment, executing test cases includes: loading the structured test script associated with the test case and executing the test case according to the test environment configuration parameters; when executing the test case, collecting the execution status and response data of the test case and obtaining the test result after the test case is completed; generating a test report based on the execution status, response data and test result, and sending the test report to the client.

[0072] Specifically, after generating test cases, in order to run the test scripts accurately, it is necessary to load the structured test scripts associated with the test cases, and then initialize the test environment according to the pre-set test environment configuration parameters to lay the foundation for subsequent automated testing. Then, the test cases are executed. The environment test configuration parameters may include server address, port number, database connection information, user credentials, etc., to ensure that the test environment is as consistent as possible with the actual production environment or target environment.

[0073] During test case execution, instructions in the structured test script can be executed one by one. Before and after each test case execution, the system automatically collects execution status and response data, such as HTTP response codes, response times, and response body content. This data is used to determine whether the system behaves normally in the test scenario and whether there are any unexpected security vulnerabilities. Finally, based on the acquired status codes, response times, response body content, and other data, the system behavior and the effectiveness of security protection are evaluated, resulting in a test report. It should be noted that the test report can be formatted in an easy-to-read format and includes data statistics charts, vulnerability lists, risk scores, etc., to facilitate a quick understanding of the test overview. Finally, the test report is sent to the client through a pre-defined communication channel for relevant personnel to view and analyze.

[0074] This embodiment generates test reports based on the execution of test cases, which can efficiently and accurately detect and evaluate the security of network applications, promptly discover potential vulnerabilities, and enhance the system's security protection capabilities.

[0075] This application also provides a traffic testing system. It should be noted that the traffic testing system of this application can be used to execute the traffic testing method provided in this application. The traffic testing system provided in this application is described below.

[0076] Figure 3 This is a schematic diagram of a traffic testing system provided according to an embodiment of this application, such as... Figure 3 As shown, the system includes:

[0077] The traffic acquisition layer 301 is used to collect network traffic data generated by the system under test during network communication, perform feature analysis on the network traffic data, and obtain network traffic features.

[0078] It should be noted that the system under test is the target system for security testing. During system communication, the traffic acquisition layer 301 can be deployed on key nodes of the network to intercept and capture all data packets entering and leaving the system under test in real time, thereby collecting network traffic data. Then, the traffic acquisition layer 301 parses and extracts key information that reflects request behavior patterns and system response characteristics from the captured network traffic data, that is, obtains network traffic characteristics, which provides a solid data foundation for subsequent security vulnerability identification and analysis.

[0079] It should be noted that the captured network traffic data first undergoes preprocessing, such as unpacking and formatting, to ensure that the data can be understood and processed by the subsequent analysis engine. Then, each data packet is analyzed in depth to extract its network traffic characteristics.

[0080] The feature analysis engine 302 includes a request recognition model and a field recognition model. It is used to input network traffic features into the request recognition model to obtain network analysis results of network traffic data, and to input network traffic features into the field recognition model to obtain field recognition results.

[0081] Specifically, the feature analysis engine 302 can analyze the network traffic features captured by the traffic acquisition layer 301 to identify potential security risks and vulnerabilities. This can include a request identification model and a field identification model, which analyze request behavior patterns and field security attributes, respectively. The request identification model, based on a Long Short-Term Memory (LSTM) network, identifies and analyzes the temporal dependencies of network traffic data, understanding the business logic flow of consecutive requests and discovering security issues based on request sequences. The field identification model uses an attention mechanism to focus on specific fields in network traffic, identifying abnormal behavior and potential vulnerability patterns in these fields, particularly those fields that might be used to implement unauthorized access or data tampering.

[0082] Specifically, after obtaining network traffic characteristics, these characteristics can be input into the request identification model and the field identification model, respectively. The feature analysis engine 302 can perform in-depth analysis of network traffic data from both temporal and spatial dimensions, thereby accurately identifying anomalies in request patterns and security risks in fields. This provides support for the generation of subsequent test cases. The request identification model focuses on temporal and protocol characteristics. By analyzing the temporal dependencies in the request sequence, the model identifies the logical connections and abnormal patterns between consecutive requests. Simultaneously, key fields and their attributes from the network traffic characteristics are input into the field identification model. This model uses an attention mechanism to filter and analyze fields highly correlated with security risks. Based on the changing patterns and abnormal behaviors of these fields in requests, the model can discover potential vulnerabilities such as unauthorized access and data tampering.

[0083] After analyzing network traffic characteristics using the two models mentioned above, the feature analysis engine 302 can output network analysis results and field identification results. These results include descriptions of abnormal request sequences, classifications of suspected vulnerability patterns, and security assessments of key fields.

[0084] Decision Center 303 is used to build test case strategies based on network analysis results and field identification results;

[0085] The decision center 303 constructs and adjusts test case strategies based on the network analysis results and field identification results output by the feature analysis engine 302 to ensure the depth and breadth of security testing. This guides the test case generator 304 (also known as the POC (Proof of Concept) generator) to generate specific test cases to cover various security risks that may exist in the system.

[0086] To make the testing strategy more targeted, the decision center 303 can customize the strategy template based on the first and second request environments (i.e., request environment information for consecutive request sequences and non-consecutive request sequences). By filling in the parameters in the strategy template, specific test case strategies are generated to address the testing requirements of both consecutive and non-consecutive request sequences. Finally, the constructed first and second test case strategies are integrated to ensure that all identified risk points are covered by corresponding test strategies. The decision center 303 then outputs the complete test case strategy to the test case generator 304, guiding it to generate specific test cases.

[0087] Test case generator 304 is used to transform the test case strategy into a structured test script, and generate test cases based on the structured test script.

[0088] The test case generator 304 (also known as the POC generator) can transform the descriptive content of the test case strategy output by the decision center 303 into an executable structured test script, and further generate specific test cases for automated testing tools to execute and verify the security of the system.

[0089] When the test case generator 304 receives the test case strategy from the decision center 303, it first performs strategy parsing to extract key information from the strategy (such as test scenarios, parameter requirements, expected results, etc.). Then, based on the strategy type and requirements, it selects an appropriate script template for matching. Then, based on the selected template, it transforms the descriptive information in the strategy into specific test instructions and parameters, forming a structured test script to ensure the accuracy and repeatability of the testing process.

[0090] Based on the structured test scripts, the test case generator 304 customizes and generates test cases. This process may include filling in specific parameter values ​​for the scripts, considering different test scenarios and boundary conditions, and generating multiple specific test cases to ensure that the tests cover all risk points defined in the strategy. Finally, the test cases are distributed to the test execution module for testing.

[0091] Test execution module 305 is used to execute test cases, generate test reports, and send the test reports to the client.

[0092] It should be noted that the test execution module 305 can simulate network requests and user operations in a real environment based on the test cases provided by the test case generator 304, perform security tests, collect information such as execution status and response data during the test process, and finally generate a detailed test report.

[0093] Specifically, the test execution module 305 first loads the structured test scripts provided by the test case generator 304 to initialize the test environment and ensure that the system is in a testable state, so as to eliminate the influence of external factors on the test.

[0094] Furthermore, the test execution module 305 executes the test scripts in the test cases one by one, simulating different network requests and user operations, while simultaneously monitoring the system response in real time, including but not limited to response time, status codes, and returned data, to verify the system's performance in the face of preset security risks. During the execution of each test case, the test execution module 305 can collect its execution status and response data. After all test cases have been executed, the test execution module 305 will summarize the execution status, response data, and test results, generate a detailed test report, and send it to the client.

[0095] The traffic testing system provided in this application embodiment includes a traffic acquisition layer 301 for collecting network traffic data generated by the system under test during network communication, performing feature analysis on the network traffic data to obtain network traffic features; a feature analysis engine 302, including a request identification model and a field identification model, for inputting network traffic features into the request identification model to obtain network analysis results of the network traffic data, and inputting network traffic features into the field identification model to obtain field identification results; a decision center 303 for constructing test case strategies based on the network analysis results and field identification results; and a test case generator 304 for structurally transforming the test case strategies to obtain structured test scripts, and generating test cases based on the structured test scripts; and a test execution... The execution module 305 is used to execute test cases and generate test reports, which are then sent to the client. This solves the technical problem of low accuracy in generating test cases when facing dynamically changing business logic in a microservice architecture. Through the collaborative operation of the traffic acquisition layer 301, feature analysis engine 302, decision center 303, test case generator 304, and test execution module 305, network traffic data is first analyzed to obtain network traffic features. These features are then input into the request recognition model and the field recognition model, respectively. Test cases are constructed based on the network analysis results and field recognition results output by the models, and the test cases are executed. This improves the accuracy of generated test cases, thereby enhancing the accuracy and efficiency of vulnerability detection.

[0096] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0097] Example 2

[0098] This application also provides a traffic testing device. It should be noted that the traffic testing device of this application can be used to execute the traffic testing method provided in this application. The traffic testing device provided in this application is described below.

[0099] According to an embodiment of this application, an apparatus for implementing the above-described flow rate testing method is also provided. Figure 4 This is a schematic diagram of a flow rate testing device provided according to an embodiment of this application, such as... Figure 4 As shown, the device includes: a data acquisition unit 40, an input unit 41, and a first construction unit 42.

[0100] The acquisition unit 40 is used to acquire network traffic data generated by the system under test during network communication, perform feature analysis on the network traffic data, and obtain network traffic features.

[0101] Input unit 41 is used to input network traffic features into the request recognition model to obtain network analysis results of network traffic data, and to input network traffic features into the field recognition model to obtain field recognition results. The request recognition model is used to identify the relationship between different requests in network traffic data based on network traffic features. The network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in network traffic data. The field recognition model is used to locate and identify fields in network traffic data. The field recognition result refers to the recognition result of whether the field in network traffic data is a preset field.

[0102] The first construction unit 42 is used to construct test cases based on network analysis results and field identification results, and to execute test cases, wherein the test cases are used to test the system to be detected.

[0103] The traffic testing device provided in this application embodiment collects network traffic data generated by the system under test during network communication through the acquisition unit 40, performs feature analysis on the network traffic data to obtain network traffic features; the input unit 41 inputs the network traffic features into a request identification model to obtain network analysis results of the network traffic data, and inputs the network traffic features into a field identification model to obtain field identification results. The request identification model is used to identify the relationship between different requests in the network traffic data based on the network traffic features; the network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in the network traffic data; and the field identification model is used to locate and identify fields in the network traffic data. The field identification results refer to the network... The first construction unit 42 constructs test cases based on the network analysis results and field recognition results, and executes the test cases. The test cases are used to test the system to be detected. This solves the technical problem of low accuracy in generating test cases when facing dynamically changing business logic under a microservice architecture. By performing feature analysis on the network traffic data, network traffic features are obtained. The network traffic features are input into the request recognition model and the field recognition model respectively. Test cases are constructed based on the network analysis results and field recognition results output by the models, and the test cases are executed. This achieves the technical effect of improving the accuracy of generating test cases, thereby improving the accuracy and efficiency of vulnerability detection.

[0104] Optionally, in the traffic testing device provided in this application embodiment, the input unit 41 includes: an extraction module, used to extract the time nodes and request parameters of M requests associated with network traffic data from network traffic characteristics, to obtain M time nodes and M sets of request parameters, where M is a positive integer; a judgment module, used to judge whether the M requests are continuous based on the M time nodes and M sets of request parameters, and if there are N continuous requests among the M requests, to generate a continuous request sequence based on the N requests, where N is less than or equal to M and N is a positive integer; and a first generation module, used to generate a non-continuous request sequence based on the M requests, and to generate network analysis results based on the continuous request sequence and the non-continuous request sequence.

[0105] Optionally, in the traffic testing device provided in this application embodiment, the input unit 41 includes: an identification module, used to identify Y fields in the network traffic features by the attention layer of the field identification model to obtain Y field weights, where Y is a positive integer; and a first acquisition module, used to acquire a weight threshold, and if there are K field weights greater than or equal to the weight threshold among the Y field weights, generate a field identification result based on the fields corresponding to the K field weights, where K is less than or equal to Y and K is a positive integer.

[0106] Optionally, in the traffic testing device provided in this application embodiment, the first construction unit 42 includes: a determination module, used to determine the request sequence type to which K fields associated with the field identification result belong based on the network analysis result, wherein the request sequence type includes continuous request sequence type and non-continuous request sequence type; a second acquisition module, used to acquire the vulnerability pattern corresponding to the K fields when the request sequence type to which the K fields belong is continuous request sequence type, and acquire a first policy template based on the K vulnerability patterns, wherein the vulnerability patterns include at least: improper cross-origin resource configuration, lack of cross-site request protection, and unauthorized access; a third acquisition module, used to acquire the request environment of the request sequence to which the K fields belong, and obtain a first request environment; and a filling module, used to fill the parameters of the first policy template according to the first request environment, obtain a first test case policy, and construct test cases based on the first test case policy.

[0107] Optionally, in the traffic testing apparatus provided in this application embodiment, the apparatus further includes: a filtering unit, configured to, after determining the request sequence type to which the K fields associated with the field identification results belong based on the network analysis results, filter out a second strategy template from the first strategy template according to the K vulnerability patterns when the request sequence type to which the K fields belong is a non-continuous request sequence type; an acquisition unit, configured to acquire the request environment of the request sequence to which the K fields belong, obtain a second request environment, and fill the parameters of the second strategy template according to the second request environment to obtain a second test case strategy; and a second construction unit, configured to construct test cases based on the second test case strategy.

[0108] Optionally, in the traffic testing device provided in this application embodiment, the first construction unit 42 includes: a fourth acquisition module, used to acquire a test case strategy determined based on network analysis results and field identification results, wherein the test case strategy includes a first test case strategy and a second test case strategy; and a conversion module, used to perform structural conversion on the test case strategy to obtain a structured test script, and generate test cases based on the structured test script.

[0109] Optionally, in the traffic testing device provided in this application embodiment, the first construction unit 42 includes: a loading module, used to load the structured test script associated with the test case and execute the test case according to the test environment configuration parameters; a collection module, used to collect the execution status and response data of the test case when executing the test case, and obtain the test result after the test case is completed; and a second generation module, used to generate a test report based on the execution status, response data and test result, and send the test report to the client.

[0110] It should be noted that the acquisition unit 40, input unit 41, and first construction unit 42 mentioned above correspond to steps S201 to S203 in Embodiment 1. The instances and application scenarios implemented by the above units and corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0111] Example 3

[0112] Embodiments of this application may provide a computer terminal, which may be any computer terminal device in a group of computer terminals. Optionally, in this embodiment, the aforementioned computer terminal may also be replaced with a mobile terminal or an electronic device, etc.

[0113] Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.

[0114] In this embodiment, the computer terminal described above can execute the following steps in the traffic testing method: collecting network traffic data generated by the system under test during network communication; performing feature analysis on the network traffic data to obtain network traffic features; inputting the network traffic features into a request identification model to obtain network analysis results of the network traffic data; inputting the network traffic features into a field identification model to obtain field identification results, wherein the request identification model is used to identify the relationship between different requests in the network traffic data based on the network traffic features; the network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in the network traffic data; the field identification model is used to locate and identify fields in the network traffic data; and the field identification results refer to the identification results of whether the fields in the network traffic data are preset fields; constructing test cases based on the network analysis results and field identification results, and executing the test cases, wherein the test cases are used to test the system under test.

[0115] Optionally, the computer terminal described above can execute the following steps in the traffic testing method: extract the time nodes and request parameters of M requests associated with network traffic data from network traffic characteristics to obtain M time nodes and M sets of request parameters, where M is a positive integer; determine whether the M requests are continuous based on the M time nodes and M sets of request parameters; if N requests are continuous among the M requests, generate a continuous request sequence based on the N requests, where N is less than or equal to M and N is a positive integer; generate a non-continuous request sequence based on the M requests; and generate network analysis results based on the continuous request sequence and the non-continuous request sequence.

[0116] Optionally, the computer terminal described above can execute the following steps in the traffic testing method: the attention layer of the field recognition model identifies Y fields in the network traffic features to obtain Y field weights, where Y is a positive integer; obtain the weight threshold; if there are K field weights among the Y field weights that are greater than or equal to the weight threshold, generate field recognition results based on the fields corresponding to the K field weights, where K is less than or equal to Y and K is a positive integer.

[0117] Optionally, the computer terminal described above can execute the following steps in the traffic testing method: determining the request sequence type of the K fields associated with the field identification results based on network analysis results, wherein the request sequence type includes continuous request sequence type and non-continuous request sequence type; if the request sequence type of the K fields is a continuous request sequence type, obtaining the vulnerability patterns corresponding to the K fields, obtaining a first policy template based on the K vulnerability patterns, wherein the vulnerability patterns at least include: improper cross-origin resource configuration, lack of cross-site request protection, and unauthorized access; obtaining the request environment of the request sequence to which the K fields belong, obtaining a first request environment; filling the parameters of the first policy template according to the first request environment to obtain a first test case policy, and constructing test cases based on the first test case policy.

[0118] Optionally, the computer terminal described above can execute the following steps in the traffic testing method: when the request sequence type to which the K fields belong is a non-continuous request sequence type, select a second strategy template from the first strategy template according to the K vulnerability patterns; obtain the request environment of the request sequence to which the K fields belong, obtain the second request environment, fill the parameters of the second strategy template according to the second request environment, and obtain the second test case strategy; construct test cases based on the second test case strategy.

[0119] Optionally, the computer terminal described above can execute the program code for the following steps in the traffic testing method: obtaining a test case strategy determined based on network analysis results and field identification results, wherein the test case strategy includes a first test case strategy and a second test case strategy; performing structural transformation on the test case strategy to obtain a structured test script, and generating test cases based on the structured test script.

[0120] Optionally, the computer terminal described above can execute the following steps in the traffic testing method: load the structured test script associated with the test case and execute the test case according to the test environment configuration parameters; while executing the test case, collect the execution status and response data of the test case and obtain the test results after the test case is completed; generate a test report based on the execution status, response data and test results, and send the test report to the client.

[0121] Optionally, Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 Only one of the components is shown: processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module, and display.

[0122] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the traffic testing method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned traffic testing method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0123] The processor can access the information and application programs stored in the memory via the transmission device to execute the steps described above in the traffic testing method.

[0124] This application provides a traffic testing scheme. It collects network traffic data generated by the system under test during network communication, performs feature analysis on the network traffic data to obtain network traffic features, inputs these features into a request identification model to obtain network analysis results, and inputs them into a field identification model to obtain field identification results. The request identification model is used to identify the relationships between different requests in the network traffic data based on the network traffic features. The network analysis results indicate the correlation and temporal sequence analysis results between different requests in the network traffic data. The field identification model is used to locate and identify fields in the network traffic data. The field identification results indicate which fields in the network traffic data are... The system identifies whether the results are from preset fields. Based on network analysis and field identification results, test cases are constructed and executed. These test cases are used to test the system under test. This addresses the technical problem of low accuracy in generating test cases when facing dynamically changing business logic in a microservice architecture. By performing feature analysis on network traffic data, network traffic features are obtained. These features are then input into the request identification model and the field identification model. Based on the network analysis and field identification results output by the models, test cases are constructed and executed. This improves the accuracy of generated test cases, thereby enhancing the accuracy and efficiency of vulnerability detection.

[0125] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0126] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0127] Example 4

[0128] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the traffic testing method provided in Embodiment 1.

[0129] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0130] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: collecting network traffic data generated by the system under test during network communication; performing feature analysis on the network traffic data to obtain network traffic features; inputting the network traffic features into a request identification model to obtain network analysis results of the network traffic data; inputting the network traffic features into a field identification model to obtain field identification results, wherein the request identification model is used to identify the relationship between different requests in the network traffic data based on the network traffic features; the network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in the network traffic data; the field identification model is used to locate and identify fields in the network traffic data; and the field identification results refer to the identification results of whether a field in the network traffic data is a preset field; constructing test cases based on the network analysis results and the field identification results, and executing the test cases, wherein the test cases are used to test the system under test.

[0131] This application also provides a computer program product, which, when executed on a data processing device, is suitable for performing test method steps for traffic flow.

[0132] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0133] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device 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. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0135] The units described 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 can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0137] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, 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 steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0138] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for testing traffic flow, characterized in that, include: Collect network traffic data generated by the system under test during network communication, and perform feature analysis on the network traffic data to obtain network traffic features; The network traffic features are input into a request identification model to obtain network analysis results of the network traffic data. The network traffic features are also input into a field identification model to obtain field identification results. The request identification model is used to identify the relationship between different requests in the network traffic data based on the network traffic features. The network analysis results are used to indicate the analysis results of the correlation and temporal sequence between different requests in the network traffic data. The field identification model is used to locate and identify fields in the network traffic data. The field identification results refer to the identification results of whether the fields in the network traffic data are preset fields. Test cases are constructed and executed based on the network analysis results and the field identification results, wherein the test cases are used to test the system to be tested.

2. The method according to claim 1, characterized in that, The network analysis results obtained by inputting the network traffic characteristics into the request identification model and processing the network traffic data include: Extract the time nodes and request parameters of M requests associated with the network traffic data from the network traffic characteristics to obtain M time nodes and M sets of request parameters, where M is a positive integer; Based on the M time nodes and the M sets of request parameters, determine whether the M requests are consecutive. If there are N consecutive requests among the M requests, generate a consecutive request sequence based on the N requests, where N is less than or equal to M and N is a positive integer. A non-continuous request sequence is generated based on MN requests, and the network analysis result is generated based on the continuous request sequence and the non-continuous request sequence.

3. The method according to claim 1, characterized in that, The network traffic characteristics are input into the field recognition model, and the resulting field recognition results include: The attention layer of the field recognition model identifies Y fields in the network traffic features to obtain Y field weights, where Y is a positive integer; Obtain the weight threshold. If there are K field weights among the Y field weights that are greater than or equal to the weight threshold, generate the field recognition result based on the fields corresponding to the K field weights, where K is less than or equal to Y and K is a positive integer.

4. The method according to claim 1, characterized in that, The test cases are constructed based on the network analysis results and the field identification results, including: Based on the network analysis results, the request sequence types to which the K fields associated with the field identification results belong are determined, wherein the request sequence types include continuous request sequence types and non-continuous request sequence types; If the request sequence type to which the K fields belong is the continuous request sequence type, obtain the vulnerability pattern corresponding to the K fields, and obtain the first policy template according to the K vulnerability patterns. The vulnerability patterns include at least: improper cross-origin resource configuration, lack of cross-site request protection, and unauthorized access. Obtain the request environment of the request sequence to which the K fields belong, and obtain the first request environment; The first strategy template is populated with parameters according to the first request environment to obtain the first test case strategy, and the test cases are constructed based on the first test case strategy.

5. The method according to claim 4, characterized in that, After determining the request sequence type to which the K fields associated with the field identification result belong based on the network analysis results, the method further includes: If the request sequence type to which the K fields belong is the non-continuous request sequence type, a second strategy template is selected from the first strategy template according to the K vulnerability patterns; Obtain the request environment of the request sequence to which the K fields belong, to obtain the second request environment, and fill the parameters of the second strategy template according to the second request environment to obtain the second test case strategy; The test cases are constructed based on the second test case strategy.

6. The method according to claim 1, characterized in that, The test cases are constructed based on the network analysis results and the field identification results, including: Obtain a test case strategy determined based on the network analysis results and the field identification results, wherein the test case strategy includes a first test case strategy and a second test case strategy; The test case strategy is structurally transformed to obtain a structured test script, and the test cases are generated based on the structured test script.

7. The method according to claim 1, characterized in that, Executing the test cases includes: Load the structured test script associated with the test case and execute the test case according to the test environment configuration parameters; When executing the test cases, the execution status and response data of the test cases are collected, and the test results after the test cases are completed are obtained; A test report is generated based on the execution status, the response data, and the test results, and the test report is sent to the client.

8. A flow rate testing system, characterized in that, include: The traffic acquisition layer is used to collect network traffic data generated by the system under test during network communication, and to perform feature parsing on the network traffic data to obtain network traffic features. The feature analysis engine includes a request recognition model and a field recognition model, which are used to input the network traffic features into the request recognition model to process and obtain the network analysis results of the network traffic data, and to input the network traffic features into the field recognition model to process and obtain the field recognition results. The decision center is used to construct test case strategies based on the network analysis results and the field identification results; A test case generator is used to transform the test case strategy into a structured test script, and generate test cases based on the structured test script. The test execution module is used to execute the test cases, generate a test report, and send the test report to the client.

9. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the traffic testing method according to any one of claims 1 to 7.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the flow testing method according to any one of claims 1 to 7.

Images