Data processing method, data processing system, and storage medium

Abstract

The application discloses a kind of data processing method, data processing system and storage medium, it is related to data processing technical field, method includes: client obtains target object selected target crowd label, obtains the test account preconfigured for label, determine target test account from it and execute automatic login;Forwarding server intercepts interface request sent to simulation server in application running;When request belongs to preset interface request set, it is forwarded to simulation server;Simulation server obtains matched preset response data from shared expected data pool and returns client;Client provides it to application, so that application presents corresponding interaction interface or executes corresponding function logic.The application automatically completes the whole process from crowd label selection to interface presentation by preconfiguring test account and shared expected data pool, avoids different personnel repeatedly constructing account and preparing data, solves the problem of low experience efficiency caused by repetitive labor, and improves experience efficiency.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a data processing method, a data processing system, and a storage medium. Background Technology

[0002] With the rapid development of internet businesses, the operation model of applications (APPs) is becoming increasingly sophisticated. In order to improve user experience and business conversion rates, operators usually segment users into different user groups based on their different attributes (such as region, age, consumption habits, etc.) and configure differentiated operation strategies for different groups. For example, displaying different homepage layouts, pushing different marketing activities, or opening different business functions, and even achieving personalized recommendations that are "one face for a thousand people".

[0003] In actual business development and operation, product managers, operations personnel, test engineers, and other roles need to frequently verify whether the app's performance under different user strategies meets expectations. Currently, to experience these differentiated operational contents, the common approach is for testers to create corresponding test accounts based on experience requirements and prepare relevant simulated data.

[0004] However, when different people need to experience different user strategies, the process of creating accounts and preparing data must be repeated, which requires a high investment of manpower and time, resulting in low user experience efficiency. Summary of the Invention

[0005] Based on this, embodiments of the present invention provide a data processing method, a data processing system, and a storage medium to solve the problem in the prior art where different people need to repeatedly construct test accounts and prepare simulated data when experiencing strategies for different groups, resulting in low experience efficiency.

[0006] In a first aspect, embodiments of the present invention provide a data processing method, including: The client obtains the target audience tags selected by the target object in the target application, and obtains at least one test account pre-configured for the target audience tags; based on the current status information of each test account and the account operation of the target object, the client determines the target test account from the at least one test account, and uses the target test account to perform automatic login in the target application; The forwarding server intercepts the interface requests sent by the target application to the simulated server through the client during its operation; When the intercepted interface request belongs to a preset set of interface requests, the forwarding server forwards the interface request to the simulated server. The simulated server obtains first preset response data that matches the interface request from the shared expected data pool, and returns the first preset response data to the client; The client provides the first preset response data to the target application, so that the target application can present a corresponding interactive interface or execute corresponding functional logic based on the first preset response data.

[0007] Secondly, embodiments of the present invention provide a data processing system, including a client, a forwarding server, and a simulation server, wherein: The client is configured to obtain the target audience tags selected by the target object in the target application, and obtain at least one test account pre-configured for the target audience tags; determine the target test account from the at least one test account based on the current status information of each test account and the account operation of the target object, and use the target test account to perform automatic login in the target application; The forwarding server is used to intercept interface requests sent by the target application to the simulated server through the client during its operation. When the intercepted interface request belongs to a preset set of interface requests, the forwarding server is used to forward the interface request to the simulated server. The simulated server is used to obtain first preset response data that matches the interface request from the shared expected data pool, and return the first preset response data to the client; The client is used to provide the first preset response data to the target application, so that the target application can present a corresponding interactive interface or execute corresponding functional logic based on the first preset response data.

[0008] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the data processing method described above.

[0009] The beneficial effects of a technical solution provided by this invention are as follows: The client obtains the target audience tags selected by the target object in the target application, and obtains at least one pre-configured test account for the target audience tags. Based on the current status information of each test account and the account operations of the target object, a target test account is determined from the at least one test account. The target test account is then used to perform automatic login in the target application, achieving pre-configuration and automatic reuse of test accounts. Different users do not need to repeatedly construct test accounts when experiencing different audience strategies. Furthermore, the forwarding server intercepts interface requests sent by the target application to the simulation server during operation. When the intercepted interface request belongs to a preset interface request set, the forwarding server forwards the interface request to the simulation server. The simulation server obtains first preset response data matching the interface request from the shared expected data pool and returns the first preset response data to the client. The client provides the first preset response data to the target application, enabling the target application to present the corresponding interactive interface or execute the corresponding functional logic based on the first preset response data. This achieves centralized storage and shared reuse of simulation data, eliminating the need to repeatedly prepare simulation data when different users experience different audience strategies. The entire process, from selecting user tags to presenting the interface, is automatically completed by the system based on pre-configured test accounts and a shared expected data pool. This effectively avoids the process of repeatedly constructing accounts and preparing data for each user experience, thus solving the problem of low experience efficiency caused by repetitive work, reducing manpower and time costs, and improving experience efficiency. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart of a data processing system according to an embodiment of the present invention; Figure 2 This is a flowchart of a data processing method according to an embodiment of the present invention; Figure 3 This is another flowchart of a data processing method in one embodiment of the present invention; Figure 4 This is another flowchart of a data processing method in one embodiment of the present invention; Figure 5 This is another flowchart of a data processing method in one embodiment of the present invention; Figure 6 This is another flowchart of a data processing method in one embodiment of the present invention; Figure 7 This is another flowchart of a data processing method in one embodiment of the present invention. Detailed Implementation

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

[0013] This invention provides a data processing method that can be applied to, for example... Figure 1 The application environment shown. Specifically, this data processing method is applied in a data processing system, which includes, for example, […]. Figure 1 The diagram shows a client 101, a forwarding server 102, a simulation server 103, a business service backend 104, and a backend management system 105. These components communicate via a network to collaboratively complete the steps of the data processing method. The client 101 can be, but is not limited to, various personal computers, laptops, smartphones, and tablets; the forwarding server 102 and the simulation server 103 can both be servers or server clusters deployed in the cloud; the business service backend 104 can be, but is not limited to, smart terminals or business processing servers used by operations or testing personnel; the backend management system 105 can be, but is not limited to, smart terminals or management servers used by operations or testing personnel, providing a configuration interface for operations or testing personnel to maintain test accounts, user tags, and expected data; no specific limitations are imposed here.

[0014] It should be noted that the aforementioned smart terminals may include, but are not limited to, various personal computers, laptops, smartphones, and tablets; business processing servers and management servers may be servers or server clusters deployed in the cloud; no restrictions are imposed here.

[0015] Please refer to the following as well. Figures 2 to 7 This paper will elaborate on a data processing method provided by an embodiment of the present invention.

[0016] Firstly, such as Figure 2 As shown, an embodiment of the present invention provides a data processing method, including the following steps: S201: The client obtains the target audience tags selected by the target object in the target application, and obtains at least one test account pre-configured for the target audience tags; based on the current status information of each test account and the account operation of the target object, the client determines the target test account from the at least one test account, and uses the target test account to perform automatic login in the target application.

[0017] As an example, the target audience refers to the user group that needs to experience or test different operational strategies in the target application (APP). This target audience can include, but is not limited to, product managers, operations personnel, testers, or other users who need to experience the features. The target application can be any program running on the client side that provides business functions and a user interface.

[0018] Audience tags refer to pre-defined user groups used to represent different operational strategies. These groups can be categorized based on user attributes (such as region, age, spending habits, and risk level), but are not limited here. For example, audience tags can be categorized as "new users," "high-net-worth individuals," "high-risk users," "students," "white-collar workers," and "overseas users." Target audience tags, on the other hand, refer to the audience tags selected from at least one audience tag set for the target group.

[0019] A test account refers to a user account pre-configured for the target audience tags; among them, a target test account refers to a test account used for login determined from at least one test account according to preset rules.

[0020] Automatic login refers to the process by which a client logs into a target application using a target test account without requiring the user to manually enter account information.

[0021] In one possible implementation, the client can respond to a target object's audience tag selection operation triggered by a preset entry point in the target application, and obtain the target audience tag selected by the target object in the target application. The preset entry point (such as an audience experience entry control) can be embedded in the login interface of the target application. The audience tag selection operation includes the target object selecting an audience tag from a selection control in the login interface. Next, based on the target audience tag, the client queries the simulated server for the corresponding list of test accounts (i.e., obtains at least one test account pre-configured for the target audience tag). The simulated server pre-stores the mapping relationship between audience tags and test accounts, and each test account contains login credentials, which may include an account identifier (such as UID, mobile phone number, or email address) and a login password. Further, the client determines the target test account from the obtained list of test accounts (i.e., at least one test account). Specifically, based on the current status information of each test account and the target object's account operations (such as account selection operations), the client determines the target test account from the list of test accounts and uses the target test account to perform automatic login in the target application, enabling the target object to enter the target application as the target test account and experience the business scenario corresponding to the target audience tag. The above methods enable the pre-configuration and automatic reuse of test accounts, eliminating the need for different personnel to repeatedly create test accounts when experiencing different audience strategies. This reduces repetitive operations during the experience preparation process and improves the efficiency of audience strategy experience for the target application.

[0022] For example, in a financial target application, multiple user groups such as "new users", "high-value users" and "active users" are pre-set, and multiple test accounts are pre-configured for each user group. When the target user selects the "new user group" tag in the client, this "new user group" is identified as the target user group tag. Subsequently, the client can automatically query the simulation server to find at least one test account pre-configured for this "new user group," for example, returning three test accounts: A, B, and C. Next, the client determines the target test account from the three test accounts A, B, and C based on the current status information of each test account and the target user's account operations. Specifically, first, the current status information of each test account is determined, such as account occupancy, validity, and online status, to automatically exclude unavailable accounts. Second, combined with the target user's account operations (such as account selection), i.e., the user can manually click to select a specific account as the login target from the filtered list of available accounts, for example, the user selects the currently unoccupied test account A as the target test account, and uses test account A to perform automatic login in the target application, so that the target user can directly enter the application interface simulating a new user scenario to experience the operational strategies and business processes corresponding to this target user group tag.

[0023] S202: The forwarding server intercepts the interface requests sent by the target application to the simulated server through the client during runtime.

[0024] As an example, an API request refers to a network request sent by a client during the runtime of a target application to obtain data or perform operations. This request can be an HTTP / HTTPS request. The API request may include an API identifier, request method, request headers, and input parameter information.

[0025] Interception refers to the process by which the forwarding server captures and processes an interface request before it is sent to the simulated server.

[0026] In one possible implementation, after the target object performs automatic login in the target application using the target test account, the target application will send one or more interface requests to the simulation server according to the business process during operation. After the client connects to the preset network environment, the interface request first reaches the forwarding server, which intercepts and processes the interface request uniformly. After intercepting the interface request, the forwarding server parses the interface request and determines whether the interface request needs to be simulated by the simulation server. If simulation processing is required, the forwarding server forwards the interface request to the simulation server so that the simulation server can return the corresponding simulation data according to the pre-configured simulation rules, thereby ensuring that the operation process of the target application can continue to execute in the simulation environment.

[0027] S203: When the intercepted interface request belongs to the preset interface request set, the forwarding server will forward the interface request to the simulated server.

[0028] As an example, a predefined set of interface requests refers to a predefined set of interface requests that need to be processed by a simulated server. This set identifies which interface requests, under specific user tags, should be intercepted and forwarded to the simulated server for simulated responses, rather than being directly forwarded to the business service backend for processing. This predefined set of interface requests can be defined using a simulated interface mapping table. This table records the mapping relationship between user tags and interface identifiers; that is, for a specific user tag, which interface identifiers correspond to which interface requests need to be simulated. The simulated interface mapping table can be configured and maintained by operations or testing personnel through a backend management system, supporting dynamic updates for flexible adjustments to the simulation strategy. In technical implementation, the predefined set of interface requests can include those with complex processes, dependencies on specific environmental conditions, or upstream / downstream services. These interface requests are difficult to execute completely in a real business environment using test accounts and require simulated response data to ensure the integrity of the user experience.

[0029] In one possible implementation, after the forwarding server intercepts the interface request sent by the target application in step S202, the forwarding server parses the interface request to obtain the interface identifier of the interface request; and the forwarding server obtains the target audience tag corresponding to the test account currently logged into the target application, which can be obtained by querying the simulation server; subsequently, the forwarding server queries the preset interface mapping table to be simulated to determine whether the combination of interface identifier and target audience tag exists in the interface mapping table to be simulated; if it exists, it is determined that the interface request belongs to the preset interface request set and needs to be processed by the simulation server; at this time, the forwarding server encapsulates the interface request (including request method, request header, request parameters, and request body, etc.) and sends it to the simulation server, waiting for the simulation server to return simulated data; if the combination does not exist in the interface mapping table to be simulated, the forwarding server forwards the interface request to the business service backend, and the real business service processes the request. In this way, the forwarding server achieves fine-grained simulation control based on user tags and interface identifiers, enabling test accounts to bypass complex process nodes that cannot be completed and obtain complete simulation response data, thereby solving the problem of incomplete experience caused by test accounts being unable to complete the entire process.

[0030] For example, in the business process of the target application, some interface requests cannot be fully executed on the real server due to the limitations of test account data. These include interface requests involving payment, risk control review, or third-party callback nodes. Testers pre-configure these types of interface requests into the simulated interface mapping table through the backend management system. For example, the " / api / order / confirm" order confirmation interface needs to be simulated for "new users," and the " / api / loan / apply" loan application interface needs to be simulated for "high-risk users." When the target application sends an order confirmation interface request during runtime, the forwarding server first intercepts the request, parses it to obtain the interface identifier " / api / order / confirm," and obtains the target user tag corresponding to the currently logged-in account as "new users." Subsequently, the forwarding server queries the simulated interface mapping table and finds that the combination of "new users" and " / api / order / confirm" exists. It then determines that the request belongs to the preset interface request set and forwards it to the simulation server. The simulation server returns simulated order confirmation result data according to the pre-configured simulation rules, thereby ensuring that the target application can continue to complete the order process. If the currently logged-in user is a "high-net-worth individual," this combination does not exist in the simulated interface mapping table. In this case, the forwarding server directly forwards the request to the business service backend, where the real business service processes the request and obtains the real order confirmation data. This processing mechanism ensures that test accounts can bypass complex process nodes that cannot be completed and obtain complete simulated response data, thereby solving the problem of incomplete experience caused by test accounts being unable to complete the entire process.

[0031] S204: The simulated server retrieves the first preset response data that matches the interface request from the shared expected data pool and returns the first preset response data to the client.

[0032] As an example, a shared expectation data pool refers to a pre-established data storage set used to store expected response data corresponding to multiple interface requests. The data in this shared expectation data pool can be used by multiple different user groups or test scenarios.

[0033] The first preset response data refers to the simulated response data pre-configured for the interface request. This first preset response data is used to replace the data returned by the real server in a simulated environment.

[0034] In one possible implementation, after the forwarding server forwards the interface request to the simulated server, the simulated server parses the interface request and searches for a preset response data that matches the interface request in the shared expectation data pool according to the pre-configured matching rules. When a first preset response data corresponding to the interface request is matched in the shared expectation data pool, the simulated server obtains the first preset response data and returns the first preset response data as the interface response to the client.

[0035] S205: The client provides the first preset response data to the target application, so that the target application can present the corresponding interactive interface or execute the corresponding functional logic based on the first preset response data.

[0036] As an example, the interactive interface refers to the user interface displayed by the target application based on the data returned by the interface, which is used to present business information to the user and receive user operations, etc.; the functional logic refers to the business processing logic executed by the target application based on the first preset response data, such as page data rendering, business process judgment or functional status update, etc.

[0037] In one possible implementation, after the client receives the first preset response data from the simulated server, the client parses the first preset response data and transmits it to the business processing module of the target application according to the interface call mechanism of the target application. Subsequently, the target application performs business logic processing based on the first preset response data, such as rendering page elements, updating page display information, or triggering corresponding business processes based on the data content, so that the target application can complete the interface display or function execution of the corresponding business scenario in the simulated data environment.

[0038] For example, when the client receives the first preset response data corresponding to the order confirmation interface request from the simulated server, the client provides the first preset response data to the target application for processing. The first preset response data includes simulated product information, order amount, and promotional activity information. After receiving the first preset response data, the target application presents the corresponding order confirmation interactive interface according to the data content, such as displaying the product name, product price, and promotional activity prompts. At the same time, it executes the corresponding functional logic according to the first preset response data, such as calculating the total order amount and displaying the payment button, so that the target object can complete the order confirmation page experience in a simulated environment.

[0039] In summary, the beneficial effects of the technical solution provided by this embodiment of the invention are as follows: The client obtains the target audience tags selected by the target object in the target application, and obtains at least one pre-configured test account for the target audience tags. Based on the current status information of each test account and the account operations of the target object, the target test account is determined from the at least one test account, and automatic login is performed in the target application using the target test account. This achieves the pre-configuration and automatic reuse of test accounts, eliminating the need to repeatedly construct test accounts when different personnel experience different audience strategies. Furthermore, the forwarding server intercepts interface requests sent by the target application to the simulated server during operation. When the intercepted interface request belongs to a preset set of interface requests, the forwarding server will receive... The API request is forwarded to the simulated server. The simulated server retrieves the first preset response data matching the API request from the shared expected data pool and returns it to the client. The client then provides the first preset response data to the target application, enabling the target application to present the corresponding interactive interface or execute the corresponding functional logic based on the first preset response data. This ensures that no additional test package needs to be downloaded during testing, allowing test accounts to bypass complex process nodes that cannot be completed in the production environment and obtain complete simulated response data. This solves the problem of incomplete experience caused by test accounts being unable to complete the entire process and achieves centralized storage and shared reuse of simulated data. Different personnel do not need to repeatedly prepare simulated data when experiencing different user strategies. The entire process, from selecting user tags to interface presentation, is automatically completed by the system based on pre-configured test accounts and the shared expected data pool. This effectively avoids the process of repeatedly constructing accounts and preparing data for each user experience, thereby reducing manpower and time costs and improving experience efficiency.

[0040] In one embodiment, such as Figure 3 As shown, step S201, which involves identifying the target test account from at least one test account, includes the following steps: S211A: Obtain the current status information of each test account pre-configured for the target audience tags. The current status information includes at least one of the following: account occupancy status, account validity status, and account online status. S212A: Based on the current status information, select candidate test accounts that meet the preset availability conditions from at least one test account; S213A: Render a test account selection control on the target application's interface and display candidate test accounts through the test account selection control; S214A: In response to the target object selecting any candidate test account from the test account selection control, the selected candidate test account is determined as the target test account.

[0041] As an example, current status information refers to status data used to reflect the current usage status of a test account. Current status information may include at least one of account occupancy status, account validity status, and account online status. Account occupancy status indicates whether the test account is being used by another user, account validity status indicates whether the test account is available, and account online status indicates whether the test account is currently logged in.

[0042] Preset availability conditions refer to pre-defined filtering conditions used to determine whether a test account is available for use. For example, they can be set to "unoccupied and valid account" or "unoccupied and offline". The purpose is to ensure that the filtered accounts can be used normally by the current target without causing conflicts.

[0043] Candidate test accounts refer to test accounts selected based on current status information and meeting preset availability conditions.

[0044] A test account selection control is an interactive component in the target application interface used to display test accounts for the target user to select. In practice, it can be implemented as a dropdown list, a group of radio buttons, a card list, or a grid. When there is only one candidate test account, the client can directly select that account by default and skip the selection step, further improving operational efficiency.

[0045] In one possible implementation, after the target user selects a target audience tag, the client first requests the current status information of each test account pre-configured for the target audience tag from the simulation server and parses the current status information. Then, the client filters at least one test account based on preset availability conditions to determine candidate test accounts that meet the usage criteria. This effectively avoids login failures or experience interruptions due to unavailable accounts, improving system reliability and user experience. Next, the client renders a test account selection control on the target application's interface, displaying information about the candidate test accounts for the target user to choose from. When the target user selects any candidate test account through the test account selection control, the client designates the selected candidate test account as the target test account for use in the subsequent automatic login process. This achieves a complete mechanism for intelligently filtering available accounts from multiple test accounts and providing them to the target user for selection and confirmation, ensuring account availability while giving the target user a certain degree of flexibility in selection.

[0046] For example, in the target application, when the target user selects the "new user group" target group tag, the client requests the current status information of each test account pre-configured for that target group tag from the simulation server. Assume five test accounts are pre-configured for this group, with the following statuses: Test account A is currently occupied by another tester; Test account B has expired and is marked as invalid; Test account C is valid but currently online (possibly occupied by another process); Test accounts D and E are idle and valid. The client filters these test accounts based on the preset availability condition "unoccupied and valid," obtaining test accounts D and E as candidate test accounts. Subsequently, the client renders a test account selection control on the target application interface and displays test accounts D and E through this control. When the target user selects test account D in the test account selection control, the client designates test account D as the target test account for automatic login in the target application. This status filtering mechanism effectively avoids login failures or experience interruptions due to unavailable accounts, improving system reliability and user experience.

[0047] In one embodiment, such as Figure 4 As shown, step S201, which involves using the target test account to perform automatic login in the target application, includes the following steps: S211B: The client obtains the login credentials of the target test account and automatically fills the login credentials into the corresponding input area of ​​the login interface of the target application; in response to the login operation triggered by the target object, the client encapsulates the login credentials of the target test account into an automatic login request and sends it to the simulation server. S212B: The simulated server receives an automatic login request, verifies the validity of the login credentials, generates a verification code for the behavior to be verified after successful verification, and returns the verification code to the client. S213B: The client receives and displays the verification code for the behavior to be verified, obtains the verification code entered by the target object, and sends the verification code to the simulated server; S214B: Simulates the server to verify the correctness of the verification code. If the verification is successful, an authentication token is generated and returned to the client. S215B: The client writes the authentication token to the target application's session storage area to complete the automatic login of the target test account.

[0048] As an example, login credentials refer to authentication information used to verify a user's identity. They may include account identifiers (such as UID, mobile phone number, email address) and login passwords, or they may be encrypted tokens or other authentication information, which are not limited here.

[0049] The verification code for behavior pending verification refers to the verification code information generated by the simulated server after verifying the validity of the login credentials, which is used to further confirm the authenticity of the target object's behavior. It can be a graphic verification code, a slider verification code, or a click verification code, etc., and there is no limitation here; the verification code refers to the verification code information entered by the target object based on the verification code for behavior pending verification displayed by the client.

[0050] An authentication token is an authentication identifier generated by the simulated server after verifying the correctness of the verification code. It is used to identify the login session status and can be in the form of session ID, JWT token, OAuth token, or a custom encrypted string.

[0051] The session storage area refers to the data storage area in the client used by the target application to store user login session information, which can be cookies, localStorage, sessionStorage, or memory cache, etc.

[0052] In one implementation, the client first obtains the login credentials of the target test account and automatically fills them into the corresponding input area of ​​the target application's login interface. This step eliminates the need for manual input from the target user, thus achieving a convenient "one-click login" experience. Specifically, the client can manipulate DOM elements using JavaScript or directly set the text values ​​of the input boxes using native code, filling in the account identifier and login password into the corresponding input boxes. Subsequently, when the target user triggers a login operation (e.g., manually clicking the login button), the client encapsulates the target test account's login credentials into an automatic login request and sends the automatic login request to the simulated server.

[0053] After receiving an automatic login request, the simulated server verifies the validity of the login credentials, including checking whether the account identifier and login password match, whether the account is locked, whether it is within the allowed login time period, and whether it is logged in on an allowed device. After successful verification, the simulated server generates a verification code for the behavior to be verified and returns the verification code to the client.

[0054] The client receives and displays the verification code for the behavior to be verified, and presents the corresponding interactive interface according to the verification code type. For example, for an image verification code, the client loads the verification code image from the specified URL and displays the input box; for a slider verification code, the client displays the slider component and listens for the sliding event; after the target object enters the verification code according to the prompt, the client sends the verification code to the simulated server for verification.

[0055] The simulated server verifies the correctness of the CAPTCHA. When the verification is successful, it generates an authentication token and returns the token to the client. After successful verification, the simulated server can also record login logs, which may include login time and IP address. The client then writes the authentication token to the target application's session storage area. Subsequently, all requests made by the target application will automatically carry the authentication token (e.g., by adding an Authorization field to the request header) to maintain login status and identity recognition, thereby completing the automatic login of the target test account.

[0056] The above methods can achieve automatic login of target test accounts while ensuring login security, enabling target users to quickly enter the target application to experience the target audience strategy, thereby reducing the need to manually enter account information and further improving experience efficiency.

[0057] For example, when the target user selects the "new user group" tag and confirms the target test account in the target application, the client obtains the login credentials corresponding to the target test account, such as the account identifier "user_new_003" and the login password "test123456", and automatically fills the login credentials into the account input box and password input box of the target application's login interface. When the target user clicks the login button, the client encapsulates the login credentials into an automatic login request and sends it to the simulated server. After the simulated server verifies the validity of the login credentials, it generates a graphic verification code and returns the verification code image URL to the client. The client loads and displays the graphic verification code. After the target user views the verification code image and enters the correct verification code characters, the client sends the verification code information to the simulated server. After the simulated server verifies the verification, it generates a JWT token and returns it to the client. The client writes the token to localStorage, enabling the target application to recognize that the target user has completed the login, thereby allowing the target user to enter the target application and begin experiencing the business process corresponding to the "new user group".

[0058] In one embodiment, such as Figure 5 As shown, step S202, which involves intercepting the interface requests sent by the target application to the simulated server during its operation, includes the following steps: S221: Load the preset interface interception rule configuration. The interface interception rule configuration contains at least one resource locator matching pattern to be intercepted. Each resource locator matching pattern is a path matching rule built based on wildcards or regular expressions. S222: Listen for all Hypertext Transfer Protocol requests sent by clients; S223: When a target Hypertext Transfer Protocol request is detected, extract the target resource locator path from the target Hypertext Transfer Protocol request; S224: Traverse at least one resource locator matching pattern that needs to be intercepted, and determine one by one whether the target resource locator path conforms to the path matching rules defined by the currently traversed resource locator matching pattern; S225: If a resource locator matching pattern that matches the path matching rules exists, then the target Hypertext Transfer Protocol request is determined to be an interface request that needs to be intercepted, and the interface request is intercepted.

[0059] As an example, interface interception rule configuration refers to a pre-defined set of rules used to identify interface requests that need to be intercepted. This set of rules guides the forwarding server in determining whether a request sent by a client needs to be intercepted.

[0060] Resource locator matching patterns refer to rule expressions used to match network request paths. They can be built based on wildcards (such as , ?, *) or regular expressions. Wildcards are used to implement fuzzy matching of paths, such as "" matching any sequence of characters. Regular expressions are used to implement more complex path matching rules.

[0061] A Hypertext Transfer Protocol (HTTP) request refers to a network request sent by a client to a simulated server via the HTTP protocol. This request information may include interface identifiers (such as resource locator paths), request methods, request headers, and input parameters. A resource locator path is the path information in the HTTP request used to identify the location of server resources. The path matching rules are the matching rules used to determine whether a resource locator path conforms to a preset pattern.

[0062] In one possible implementation, the forwarding server loads a preset interface interception rule configuration. This interface interception rule configuration contains several resource locator matching patterns to be intercepted. For example, " / api / order / *" means to intercept all requests that start with " / api / order / ", and "^ / api / v1 / (info|profile)$" means to use regular expressions to precisely intercept the two paths " / api / v1 / info" and " / api / v1 / profile". There are no restrictions here.

[0063] The forwarding server listens for all Hypertext Transfer Protocol (HTTP) requests sent by clients. For example, it can configure client network proxies, gateway traffic mirroring, or operating system global proxies to ensure that all HTTP / HTTPS requests pass through the forwarding server. For HTTPS requests, SSL certificate decryption needs to be configured to read encrypted content.

[0064] When a target Hypertext Transfer Protocol (HTTP) request is detected, the forwarding server extracts the target resource locator (RPL) path. For example, for the HTTP request "https: / / api.example.com / api / order / confirm?uid=123", the extracted path is " / api / order / confirm"; it can also extract information such as the request method and request headers.

[0065] The forwarding server iterates through all resource locator matching patterns to be intercepted, determining one by one whether the target resource locator path conforms to the path matching rules defined in the current matching pattern. That is, for each matching pattern, the corresponding matching algorithm is executed. For example, for wildcard patterns, wildcard matching is performed (e.g., * matches any character sequence, ? matches a single character, and ** matches any level of path); for regular expression patterns, regular expression matching is performed. To improve matching efficiency, matching patterns can be pre-compiled and cached, and sorted according to matching priority; this is not specified here.

[0066] If a resource locator matching pattern that matches the path matching rules exists, the forwarding server determines that the target Hypertext Transfer Protocol request is an interface request that needs to be intercepted and intercepts the interface request; if none of the patterns match, the forwarding server directly allows the request and forwards it to the original target server (business service backend) without any interception processing. This tiered interception mechanism allows for precise control over which interfaces need to be processed, effectively avoiding unnecessary interception and forwarding of all requests, thereby improving system performance and response speed.

[0067] For example, multiple resource locator matching patterns are pre-configured, such as " / api / order / " and " / api / activity / receive.", where the former uses a wildcard to represent all order-related interface paths, and the latter uses a regular expression to match activity-related interface paths. When a client sends a Hypertext Transfer Protocol (HTTP) request during the target application's runtime, the forwarding server first listens for and obtains the request, extracting the target resource locator path from the request, such as " / api / order / confirm." Subsequently, the forwarding server iterates through the resource locator matching patterns in the interface interception rule configuration and checks whether each target resource locator path matches the corresponding path matching rule. When the result shows that " / api / order / confirm" matches the resource locator matching pattern " / api / order / *", the forwarding server determines that the target HTTP request is an interface request to be intercepted and performs subsequent processing on the interface request. If the request path is " / api / user / profile", and none of the matching patterns match, the forwarding server directly allows the request and forwards it to the business service backend for processing.

[0068] In one embodiment, such as Figure 6 As shown, step S204, which involves retrieving the first preset response data matching the interface request from the shared expected data pool, includes the following steps: S241: Parse the interface request to obtain the interface identifier and input parameter information; S242: Using the interface identifier as an index, find the corresponding expected dataset in the shared expected data pool, wherein the expected dataset contains at least one expected data item, and each expected data item is associated with and stored with an input parameter condition template and a corresponding preset response data; S243: Traverse each expected data item in the expected dataset, and for each expected data item, determine whether the input parameter information matches the input parameter condition template associated with that expected data item; S244: When there is a desired data item and its associated input parameter condition template matches the input parameter information successfully, the desired data item is determined as the target desired data item, and the corresponding preset response data is extracted from the target desired data item as the first preset response data. S245: If no matching input parameter condition template is found after traversing all expected data items in the expected dataset, an empty result indication message is generated and returned to the forwarding server so that the forwarding server forwards the interface request to the business service backend.

[0069] As an example, an API request refers to business request information sent by a target application to a server over the network during runtime. It typically includes an API identifier, request method, request headers, and input parameters. The API identifier is the unique identifier used to identify a specific API, such as the API path (e.g., " / api / order / confirm") or API name. The request method refers to the request type defined by the HTTP protocol, such as GET, POST, and PUT. The request headers are key-value pairs carrying request metadata, such as Content-Type and User-Agent. Input parameters are the business parameter data carried in the API request, which may include query parameters (key-value pairs after "?" in the URL), form parameters (application / x-www-form-urlencoded or multipart / form-data format), and fields in the JSON / XML request body. These components together constitute a complete API request. The API identifier is used to locate the specific API, and the input parameters are used to transmit business data. When simulating the server to match expected data items, the API identifier and input parameters are primarily used for judgment.

[0070] An expected dataset refers to a set of data stored in a shared expected data pool that is associated with a certain interface identifier. This data set contains at least one expected data item. An expected data item is a configuration unit used to describe the response data that should be returned under specific input parameter conditions. Each expected data item is associated with an input parameter condition template and the corresponding preset response data. An input parameter condition template is template information used to describe the matching conditions of the interface request input parameters.

[0071] Empty result indication information refers to the identification information generated when no matching input parameter condition template is found to indicate a failed match. For example, a specific HTTP status code (such as 404 Not Found) or an empty response body, which is not limited here.

[0072] In one possible implementation, after the simulated server receives an interface request forwarded by the forwarding server, it first parses the request, extracting the interface identifier and input parameter information. The interface identifier is typically a resource locator path, and the input parameter information may come from query parameters, form data, or the JSON request body, depending on the request type. Then, the simulated server uses the interface identifier as an index to search for the corresponding expected dataset in the shared expected data pool. If the corresponding expected dataset is found, it iterates through each expected data item in the dataset. For each expected data item, it determines whether the input parameter information of the current interface request matches the input parameter condition template associated with that expected data item. The input parameter condition template can define multiple matching rules. Examples of matching methods include exact matching (field equal to a certain value), range matching (field greater than or less than a certain value), set matching (field within a specified set), and combined conditions (multiple conditions connected via AND / OR). When a desired data item matches successfully, the simulated server identifies that desired data item as the target desired data item, extracts the corresponding preset response data as the first preset response data, and returns it to the forwarding server, which then forwards it to the client. If no match is found after iterating through all desired data items, the simulated server generates an empty result indication message and returns this message to the forwarding server, instructing the forwarding server to forward the original interface request to the business service backend for actual processing. Through this method, the simulated server can dynamically match the corresponding preset response data based on the interface identifier and input parameter information of the interface request, thereby improving the flexibility of interface simulation processing and ensuring that unmatched requests can be routed back to the real service, guaranteeing business continuity.

[0073] For example, when a client sends an order confirmation API request, the request path is " / api / order / confirm", and the input parameters include the product ID "sku123" and the order amount "299.00". The simulated server parses the API identifier " / api / order / confirm" and searches for the corresponding expected dataset in the shared expected data pool. This expected dataset contains multiple expected data items; for example, the input parameter template for expected data item A is "sku=sku123". "ANDamount<500" corresponds to the preset response data of order confirmation success; the input parameter template of expected data item B is "sku=sku456", and the corresponding preset response data is out-of-stock notification response; the simulated server traverses each expected data item and determines whether the current input parameter information meets the conditions of expected data item A: sku equals sku123 and the amount 299 is less than 500, and the match is successful; therefore, the simulated server determines expected data item A as the target expected data item, extracts the preset order confirmation success response data from it as the first preset response data, and returns it to the client; if the current input parameter information is "sku=sku789", and none of the expected data items match after traversing all of them, the simulated server generates an empty result indication message (such as HTTP 404) and returns it to the forwarding server, which forwards the request to the business service backend for processing.

[0074] In one embodiment, the shared expected data pool is constructed in the following manner: The simulated server receives the expected data configuration instruction sent by the backend management system. The expected data configuration instruction includes the target interface identifier, at least one set of input parameter condition templates, and the response data template corresponding to each set of input parameter condition templates. The simulated server checks whether the corresponding expected dataset already exists in the shared expected data pool based on the target interface identifier; If it does not exist, the simulation server creates a new expected dataset in the shared expected data pool, indexed by the target interface identifier; If it exists, the simulation server will locate the existing desired dataset; The simulation server encapsulates at least one set of input parameter condition templates and corresponding response data templates into expected data items, and stores each expected data item in the expected dataset in association. After storage is complete, the simulated server returns a confirmation message to the backend management system indicating that the construction or update of the shared expected data pool has been completed.

[0075] As an example, the expected data configuration instruction refers to the instruction information sent by the backend management system to the simulation server. The instruction includes the target interface identifier, at least one set of input parameter condition templates, and the response data template corresponding to each set of input parameter condition templates.

[0076] A response data template is a template information used to describe the data content that an interface should return under specific input parameter conditions. It can be a complete HTTP response, including status codes, response headers, and response bodies.

[0077] A confirmation message is a message returned by the simulation server to the backend management system after the expected data storage or update is completed. It is used to indicate that the shared expected data pool construction or update operation has been successfully completed and can usually include information such as the operation result, the number of data items affected, and timestamps.

[0078] In one possible implementation, the shared expected data pool can be constructed as follows: A simulated server receives an expected data configuration instruction from the backend management system. This instruction carries a target interface identifier, at least one set of input parameter condition templates, and a corresponding response data template for each set of input parameter condition templates. The simulated server first checks whether an expected dataset indexed by the target interface identifier already exists in the shared expected data pool. If no corresponding expected dataset exists, the simulated server creates a new expected dataset in the shared expected data pool, using the target interface identifier as the index. If a corresponding expected dataset already exists, the simulated server directly locates the existing expected dataset. Subsequently, the simulated server encapsulates each set of input parameter condition templates and its corresponding response data template in the instruction into independent expected data items, and stores these expected data items in the aforementioned expected dataset. Each expected data item may contain metadata information such as a unique identifier, input parameter condition template, response data template, creation time, and update time, facilitating subsequent individual querying, updating, or deletion. After storage, the simulated server returns a confirmation message to the backend management system indicating that the construction or update operation of the shared expected data pool has been completed. The above construction method enables the dynamic creation and updating of the shared expected data pool, allowing the simulation server to match the corresponding preset response data according to the interface request, thereby ensuring the integrity and consistency of the interface simulation processing.

[0079] For example, the backend management system sends a desired data configuration instruction to the simulation server, where the target interface is identified as " / api / order / confirm", and the input parameter condition template includes two sets: the first set of conditions is "sku=12345", and the second set of conditions is "sku=67890"; the response data templates corresponding to each set of input parameter condition templates are simulated order confirmation information A (indicating order success) and simulated order confirmation information B (indicating product out of stock); after receiving the desired data configuration instruction, the simulation server first checks whether a desired dataset indexed by " / api / order / confirm" already exists in the shared desired data pool; if it finds that it does not exist, it creates a new desired dataset in the shared desired data pool and indexes it as " / api / order / confirm". Using "firm" as the index, the simulation server then encapsulates the first set of input parameter templates "sku=12345" and its corresponding response data template (simulated order confirmation information A) into the first expected data item, and encapsulates the second set of input parameter templates "sku=67890" and its corresponding response data template (simulated order confirmation information B) into the second expected data item. These two expected data items are then associated and stored in the newly created expected dataset. After storage, the simulation server returns a confirmation message to the backend management system, indicating that the expected dataset " / api / order / confirm" in the shared expected data pool has been successfully created. Thus, when an order confirmation interface request with input parameter sku=12345 is received subsequently, this expected data item can be matched and the corresponding simulated order confirmation information A can be returned.

[0080] In one embodiment, such as Figure 7 As shown, step S201, which involves obtaining the target audience tags selected in the target application, includes the following steps: S211C: The client renders the crowd experience entry control on the login screen of the target application and listens for the trigger event of the crowd experience entry control; S212C: When a trigger event for the crowd experience entry control is detected, the client generates a crowd tag list query request and sends the crowd tag list query request to the simulated server. S213C: Simulates the server receiving a query request for a population tag list, queries the pre-stored population tag library, and obtains the population tag list data, which contains at least one population tag. S214C: Simulates the server returning the list of audience tags to the client; S215C: The client receives the list of audience tags and renders an audience tag selection overlay on the current interface of the target application, displaying at least one audience tag in the audience tag selection overlay in list form; when the target object selects any audience tag in the audience tag selection overlay, the selected audience tag is determined as the target audience tag.

[0081] As an example, the crowd experience entry control refers to the operation control provided by the client on the login interface of the target application to trigger the crowd tag selection function. Specifically, it can be designed in the form of icons, text links, buttons, switches or special gestures, such as the "Crowd Experience" button.

[0082] Triggering events refer to the actions of a target object in interacting with the user experience entry control, such as clicking, touching, or being triggered by a shortcut key.

[0083] A crowd tag list query request is a network request generated by the client and sent to the simulated server to obtain pre-stored crowd tag list data. This crowd tag list query request may include parameters such as client version information, device identifier, and operating system type.

[0084] The audience tag library refers to a database or cache stored in the simulation server, used to save pre-configured audience classification identification information and its related attributes, such as tag ID, tag name, tag description, icon URL, color code, creation time, status, etc.

[0085] The audience tag list data refers to the collection of at least one audience tag returned by the simulated server to the client. Each audience tag contains at least an audience tag identifier (such as crowd_id) and an audience tag name (such as "new user audience").

[0086] The audience tag selection overlay refers to the interface rendered on top of the target application's current screen to display a list of audience tags. It can be a card-style pop-up that appears on a semi-transparent overlay and supports scrolling, searching, and canceling operations.

[0087] In one possible implementation, the client renders a user experience entry control on the login screen of the target application and continuously listens for trigger events of the target object on this control through an event listener mechanism (such as addEventListener). When a trigger event is detected, the client generates a user tag list query request and sends the request to the simulated server. After receiving the request, the simulated server queries the pre-stored user tag library, obtains all or part of the currently available user tag list data, and returns it to the client in JSON format. After receiving the user tag list data, the client renders a user tag selection overlay on the current screen of the target application, displaying at least one user tag in list form. Within the overlay, each tag can display its name, icon, color code, etc., for easy identification. The overlay also provides a search box for the target audience to quickly find specific tags, and a "Cancel" button at the bottom allows closing the overlay without making a selection. The client listens for the target audience's selection of any audience tag within the overlay (e.g., clicking the row containing the tag). When a selection is detected, the client identifies the audience tag corresponding to the selected tag as the target audience tag, closes the audience tag selection overlay, and returns to the login screen to prepare for the subsequent login process. The client can also display the currently selected tag name on the login screen, such as "Current Experience Audience: New User Audience," so the target audience can confirm their experience status. This approach enables the target audience to quickly select the desired audience tag on the client interface without manual input or repeated background searches. It also provides foundational data for obtaining test accounts and executing automatic login, effectively improving the convenience and efficiency of the experience process.

[0088] For example, an operations staff member A from an internet company sees a "Target Audience Experience" button (target audience experience entry control) on the login screen of a target application. Clicking this button triggers an event, and the client generates a request to query the audience tag list and sends it to the simulated server. The simulated server queries its pre-stored audience tag library, retrieves the currently configured "New User Audience," "High-Net-Worth Audience," and "High-Risk User Audience" tags and their related information, and returns a list containing these three tags to the client. The client renders an audience tag selection overlay above the login screen, displaying "New User Audience," "High-Net-Worth Audience," and "High-Risk User Audience" in list format, with each tag displaying its name and corresponding icon. When operations staff member A clicks on the "New User Audience" tag in the overlay, the client detects the selection, identifies the tag as the target audience tag, and closes the overlay. At this point, the login screen displays "Current Experience Audience: New User Audience," indicating that operations staff member A has entered the new user audience experience mode. Subsequently, corresponding test accounts and simulated data will be provided based on this target audience tag to achieve differentiated operational content experiences for new user audiences.

[0089] In one embodiment, such as Figure 1 As shown, the method also includes the following steps: S206: When the intercepted interface request does not belong to the preset interface request set, the forwarding server will forward the interface request to the business service backend; S207: The business service backend generates second preset response data based on the interface request and returns the second preset response data to the client.

[0090] S208: The client provides the second preset response data to the target application so that the target application can present the corresponding interactive interface or execute the corresponding functional logic based on the second preset response data.

[0091] As an example, the second preset response data refers to the response data generated by the business service backend according to the predefined static configuration. The second preset response data can be dynamically generated based on real business logic and real-time data, or it can be static data returned according to a fixed template. The static configuration refers to the fixed response data template or rules pre-set in the business service backend, which is used to return preset response content under specific conditions to ensure that the interface request can obtain a valid response.

[0092] In one possible implementation, after intercepting an interface request, the forwarding server first determines whether the request belongs to a preset set of interface requests. This determination can be based on whether the combination of the interface identifier and the currently logged-in target user tag exists in the mapping table of interfaces to be simulated. If this combination does not exist in the mapping table, the request is determined not to belong to the preset set of interface requests and does not need to be processed by the simulated server. At this point, the forwarding server directly forwards the interface request to the business service backend, where the real business service processes the request. During forwarding, the forwarding server maintains the original request information unchanged, including the request method, request headers, request parameters, and request body, and sends the request to the real address of the business service backend via an HTTP client. After receiving the interface request, the business service backend executes business logic based on the request content, which may involve several... Operations such as database queries, cache reads, and external service calls generate real response data. This real response data is returned to the forwarding server as the second preset response data, and then the forwarding server returns it to the client. The second preset response data can be dynamically generated based on real-time data or fixed response content returned according to a predefined static configuration. After receiving the second preset response data, the client provides it to the target application. The target application parses the data and renders the corresponding interactive interface or executes the corresponding functional logic based on the data content. Through the above method, it is ensured that requests that do not belong to the preset interface request set can still obtain real data normally without affecting the normal function of the application. This achieves seamless switching between simulated and real requests, while ensuring that the real data in the production environment is not contaminated by simulated data.

[0093] For example, during runtime, the target application sends an API request to query user points information, with the request path " / api / user / points". The forwarding server intercepts this request, parses it to obtain the API identifier " / api / user / points", and identifies the target user group tag corresponding to the currently logged-in account as "new user group". The forwarding server queries the simulated API mapping table and finds that the combination of "new user group" and " / api / user / points" does not exist in the table, thus determining that the request does not belong to the preset API request set. Therefore, the forwarding server directly forwards the request to the business service backend. Upon receiving the request, the business service backend generates a second preset response data based on a predefined static configuration, such as returning fixed-format points data {"points":100, "level":"silver card"}, and returns this response data to the forwarding server, which then returns it to the client. Upon receiving the second preset response data, the client provides it to the target application, which parses it and displays the user's points and membership level.

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

[0095] Secondly, such as Figure 1 As shown, this embodiment of the invention provides a data processing system, including a client 101, a forwarding server 102, and a simulation server 103, wherein: The client 101 is used to obtain the target audience tag selected by the target object in the target application, and obtain at least one test account pre-configured for the target audience tag; determine the target test account from the at least one test account, and use the target test account to perform automatic login in the target application; The forwarding server 102 is used to intercept interface requests sent by the target application to the simulated server through the client during the running process; When the intercepted interface request belongs to a preset set of interface requests, the forwarding server 102 is used to forward the interface request to the simulation server 103. The simulated server 103 is used to obtain first preset response data that matches the interface request from the shared expected data pool, and return the first preset response data to the client 101. The client 101 is used to provide the first preset response data to the target application, so that the target application can present a corresponding interactive interface or execute corresponding functional logic based on the first preset response data.

[0096] In one embodiment, determining the target test account from the at least one test account includes: Obtain the current status information of each test account pre-configured for the target audience tags, wherein the current status information includes at least one of account occupancy status, account validity status, and account online status; Based on the current status information, candidate test accounts that meet the preset availability conditions are selected from the at least one test account; Render a test account selection control on the interface of the target application, and display the candidate test accounts through the test account selection control; In response to the target object selecting any of the candidate test accounts from the test account selection control, the selected candidate test account is determined as the target test account.

[0097] In one embodiment, performing automatic login in the target application using the target test account includes: The client 101 is used to obtain the login credentials of the target test account and automatically fill the login credentials into the corresponding input area of ​​the login interface of the target application; in response to the login operation triggered by the target object, the client encapsulates the login credentials of the target test account into an automatic login request and sends it to the simulation server 103. The simulated server 103 is used to receive the automatic login request, verify the validity of the login credentials, generate a verification code for the behavior to be verified after the verification is successful, and return the verification code for the behavior to be verified to the client 101. The client 101 is used to receive and display the verification code of the behavior to be verified, obtain the verification code input by the target object, and send the verification code to the simulation server 103; The simulated server 103 is used to verify the correctness of the verification code. If the verification is successful, an authentication token is generated and returned to the client 101. The client 101 is used to write the authentication token into the session storage area of ​​the target application to complete the automatic login of the target test account.

[0098] In one embodiment, intercepting the interface requests sent by the target application to the simulated server 103 during runtime includes: Load the preset interface interception rule configuration, which includes at least one resource locator matching pattern to be intercepted, and each resource locator matching pattern is a path matching rule constructed based on wildcards or regular expressions; Listen for all Hypertext Transfer Protocol requests sent by the client 101; When a target Hypertext Transfer Protocol request is detected, the target resource locator path in the target Hypertext Transfer Protocol request is extracted. Iterate through the at least one resource locator matching pattern that needs to be intercepted, and determine one by one whether the target resource locator path conforms to the path matching rules defined by the currently traversed resource locator matching pattern; If a resource locator matching pattern that matches the path matching rules exists, the target Hypertext Transfer Protocol request is determined to be an interface request that needs to be intercepted, and the interface request is intercepted.

[0099] In one embodiment, the data processing system further includes a business service backend 104; the step of obtaining first preset response data matching the interface request from the shared expected data pool includes: Parse the interface request to obtain the interface identifier and input parameter information. Using the interface identifier as an index, the corresponding expected dataset is searched in the shared expected data pool, wherein the expected dataset contains at least one expected data item, and each expected data item is associated with and stored with an input parameter condition template and a corresponding preset response data; Iterate through each expected data item in the expected dataset, and for each expected data item, determine whether the input parameter information matches the input parameter condition template associated with that expected data item; When there is a desired data item and its associated input parameter condition template successfully matches the input parameter information, the desired data item is determined as the target desired data item, and the corresponding preset response data is extracted from the target desired data item as the first preset response data. If, after traversing all expected data items in the expected dataset, no input parameter condition template matching the input parameter information is found, then an empty result indication is generated and returned to the forwarding server 102, so that the forwarding server 102 forwards the interface request to the business service backend 104.

[0100] In one embodiment, the data processing system further includes a backend management system 105; the shared expected data pool is constructed in the following manner: The simulated server 103 is used to receive the expected data configuration instruction sent by the background management system 105. The expected data configuration instruction includes a target interface identifier, at least one set of input parameter condition templates, and a response data template corresponding to each set of input parameter condition templates. The simulation server 103 is used to check whether the corresponding expected dataset already exists in the shared expected data pool based on the target interface identifier; If it does not exist, the simulation server 103 is used to create a new expected dataset in the shared expected data pool, indexed by the target interface identifier; If it exists, the simulation server 103 is used to locate the existing desired dataset; The simulation server 103 is used to encapsulate the at least one set of input parameter condition templates and the corresponding response data templates into expected data items, and to store each expected data item in the expected dataset. After storage is completed, the simulated server 103 returns a confirmation message to the background management system 105 indicating that the construction or update of the shared expected data pool has been completed.

[0101] In one embodiment, obtaining the target audience tags selected by the target object in the target application includes: The client 101 is used to render a crowd experience entry control on the login interface of the target application and listen for trigger events on the crowd experience entry control. When a trigger event for the crowd experience entry control is detected, the client 101 generates a crowd tag list query request and sends the crowd tag list query request to the simulated server 103. The simulated server 103 is used to receive the population tag list query request, query the pre-stored population tag library, and obtain the population tag list data, wherein the population tag list data contains at least one population tag. The simulated server 103 is used to return the population tag list data to the client 101; The client 101 is used to receive the population tag list data and render a population tag selection overlay on the current interface of the target application, displaying at least one population tag in the population tag selection overlay in a list form; when the target object selects any population tag in the population tag selection overlay, the selected population tag is determined as the target population tag.

[0102] In one embodiment, the method further includes: When the intercepted interface request does not belong to the preset interface request set, the forwarding server 102 is used to forward the interface request to the business service backend 104. The business service backend 104 is used to generate second preset response data according to the interface request and return the second preset response data to the client 101; The client 101 is used to provide the second preset response data to the target application, so that the target application can present a corresponding interactive interface or execute corresponding functional logic based on the second preset response data.

[0103] It should be noted that the specific limitations on the data processing system can be found in the limitations on the data processing methods mentioned above, and will not be repeated here.

[0104] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the data processing method described above, for example... Figure 2 The steps shown are S201-S208, or... Figures 2 to 7 As shown, to avoid repetition, it will not be repeated here. Alternatively, when this computer program is executed by the processor, it implements the functions of the aforementioned data processing system, for example... Figure 1The functions of the client 101, forwarding server 102, simulation server 103, business service backend 104, and backend management system 105 in the data processing system shown are not described again here to avoid duplication. The computer-readable storage medium may be non-volatile or volatile.

[0105] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0106] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A data processing method, characterized by, include: The client obtains the target audience tags selected by the target object in the target application, and obtains at least one test account pre-configured for the target audience tags; Based on the current status information of each test account and the account operation of the target object, a target test account is determined from the at least one test account, and the target test account is used to perform automatic login in the target application; The forwarding server intercepts the interface requests sent by the target application to the simulated server through the client during its operation; When the intercepted interface request belongs to a preset set of interface requests, the forwarding server forwards the interface request to the simulated server. The simulated server obtains first preset response data that matches the interface request from the shared expected data pool, and returns the first preset response data to the client; The client provides the first preset response data to the target application, so that the target application can present a corresponding interactive interface or execute corresponding functional logic based on the first preset response data.

2. The method of claim 1, wherein, The step of determining the target test account from the at least one test account based on the current status information of each test account and the account operation of the target object includes: Obtain the current status information of each test account pre-configured for the target audience tags, wherein the current status information includes at least one of account occupancy status, account validity status, and account online status; Based on the current status information, candidate test accounts that meet the preset availability conditions are selected from the at least one test account; Render a test account selection control on the interface of the target application, and display the candidate test accounts through the test account selection control; In response to the target object selecting any of the candidate test accounts from the test account selection control, the selected candidate test account is determined as the target test account.

3. The method of claim 1, wherein, The step of using the target test account to perform automatic login in the target application includes: The client obtains the login credentials of the target test account and automatically fills the login credentials into the corresponding input area of ​​the login interface of the target application; in response to the login operation triggered by the target object, the client encapsulates the login credentials of the target test account into an automatic login request and sends it to the simulation server. The simulated server receives the automatic login request, verifies the validity of the login credentials, generates a verification code for the behavior to be verified after the verification is successful, and returns the verification code to the client. The client receives and displays the verification code for the behavior to be verified, obtains the verification code input by the target object, and sends the verification code to the simulation server; The simulated server verifies the correctness of the verification code. If the verification passes, it generates an authentication token and returns it to the client. The client writes the authentication token into the session storage area of ​​the target application to complete the automatic login of the target test account.

4. The method of claim 1, wherein, The interception of interface requests sent by the target application to the simulated server during runtime includes: Load the preset interface interception rule configuration, which includes at least one resource locator matching pattern to be intercepted, and each resource locator matching pattern is a path matching rule constructed based on wildcards or regular expressions; Listen for all Hypertext Transfer Protocol requests sent by the client; When a target Hypertext Transfer Protocol request is detected, the target resource locator path in the target Hypertext Transfer Protocol request is extracted. Iterate through the at least one resource locator matching pattern that needs to be intercepted, and determine one by one whether the target resource locator path conforms to the path matching rules defined by the currently traversed resource locator matching pattern; If a resource locator matching pattern that matches the path matching rules exists, the target Hypertext Transfer Protocol request is determined to be an interface request that needs to be intercepted, and the interface request is intercepted.

5. The method of claim 1, wherein, The step of obtaining the first preset response data matching the interface request from the shared expected data pool includes: Parse the interface request to obtain the interface identifier and input parameter information; Using the interface identifier as an index, the corresponding expected dataset is searched in the shared expected data pool, wherein the expected dataset contains at least one expected data item, and each expected data item is associated with and stored with an input parameter condition template and a corresponding preset response data; Iterate through each expected data item in the expected dataset, and for each expected data item, determine whether the input parameter information matches the input parameter condition template associated with that expected data item; When there is a desired data item and its associated input parameter condition template successfully matches the input parameter information, the desired data item is determined as the target desired data item, and the corresponding preset response data is extracted from the target desired data item as the first preset response data. If, after traversing all expected data items in the expected dataset, no input parameter condition template matching the input parameter information is found, an empty result indication is generated and returned to the forwarding server so that the forwarding server forwards the interface request to the business service backend.

6. The method of claim 5, wherein, The shared expected data pool is constructed in the following manner: The simulated server receives the expected data configuration instruction sent by the backend management system. The expected data configuration instruction includes the target interface identifier, at least one set of input parameter condition templates, and the response data template corresponding to each set of input parameter condition templates. The simulation server checks whether the corresponding expected dataset already exists in the shared expected data pool based on the target interface identifier; If it does not exist, the simulation server creates a new expected dataset in the shared expected data pool, indexed by the target interface identifier; If it exists, the simulation server locates the existing desired dataset; The simulation server encapsulates the at least one set of input parameter condition templates and the corresponding response data templates into expected data items, and stores each expected data item in the expected dataset in association. After storage is completed, the simulation server returns a confirmation message to the backend management system indicating that the construction or update of the shared expected data pool has been completed.

7. The method of claim 1, wherein, The step of obtaining the target audience tags selected by the target object in the target application includes: The client renders a crowd experience entry control on the login screen of the target application and listens for trigger events on the crowd experience entry control. When a trigger event for the crowd experience entry control is detected, the client generates a crowd tag list query request and sends the crowd tag list query request to the simulated server. The simulation server receives the population tag list query request, queries the pre-stored population tag library, and obtains the population tag list data, which contains at least one population tag. The simulation server returns the population tag list data to the client; The client receives the list of audience tags and renders an audience tag selection overlay on the current interface of the target application, displaying at least one audience tag in a list format in the audience tag selection overlay; when the target object selects any audience tag in the audience tag selection overlay, the selected audience tag is identified as the target audience tag.

8. The method of claim 1, wherein, The method further includes: When the intercepted interface request does not belong to the preset interface request set, the forwarding server forwards the interface request to the business service backend; The business service backend generates second preset response data according to the interface request, and returns the second preset response data to the client; The client provides the second preset response data to the target application, so that the target application can present a corresponding interactive interface or execute corresponding functional logic based on the second preset response data.

9. A data processing system, characterized by This includes the client, the forwarding server, and the simulation server, among which: The client is configured to obtain the target audience tags selected by the target object in the target application, and obtain at least one test account pre-configured for the target audience tags; determine the target test account from the at least one test account based on the current status information of each test account and the account operation of the target object, and use the target test account to perform automatic login in the target application; The forwarding server is used to intercept interface requests sent by the target application to the simulated server through the client during its operation. When the intercepted interface request belongs to a preset set of interface requests, the forwarding server is used to forward the interface request to the simulated server. The simulated server is used to obtain first preset response data that matches the interface request from the shared expected data pool, and return the first preset response data to the client; The client is used to provide the first preset response data to the target application, so that the target application can present a corresponding interactive interface or execute corresponding functional logic based on the first preset response data.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program, which is executed by a processor, implements the steps of the data processing method as claimed in any of claims 1 to 8.

Images