Service link verification method, system and device, equipment and storage medium

Abstract

The invention discloses a service link verification method, system and device, equipment and a storage medium, which can improve the verification efficiency of a service link. The method comprises the following steps: acquiring verification scene configuration information of a service link; generating a verification configuration identifier corresponding to the verification scene according to the verification scene configuration information of the service link; receiving a verification scene admission request sent by the first terminal based on the verification configuration identifier; in response to the verification scene admission request, adding the first terminal context information to a white list of each to-be-verified node according to the verification strategy configuration information of each to-be-verified node; receiving a verification request sent by a second terminal for the verification target; in response to the verification request, obtaining an execution result of the service link according to the verification strategy configuration information of each to-be-verified node, the white list of each to-be-verified node and the context information of the second terminal; and sending the execution result to the second terminal, so that the second terminal displays a verification result corresponding to the verification target based on the execution result.

Description

Technical Field

[0001] The present application relates to the field of link verification technology, and in particular to a service link verification method, system, device, equipment and storage medium. Background Art

[0002] During software development and product iteration, acceptance testing is a critical step in ensuring that service chains meet expectations. Due to the complexity of service chains, dynamic traffic diversion rules often prevent automated use cases from hitting designated logical branches during chain verification. For example, a page may have two versions, A and B, and an automated use case is required to verify the page performance of version B. However, the system may route the test account to version A based on dynamic traffic diversion rules (such as user feature-based diversion) without executing the logical branch for version B, resulting in chain verification failure.

[0003] Related technologies manually configure whitelists at each key node in a service link to ensure that specific logical branches of the service link are correctly triggered, thereby verifying the effectiveness of the service link. However, this verification method is not only cumbersome, but also prone to extended troubleshooting due to mismatches or omissions in the whitelist, resulting in low service link verification efficiency. Summary of the Invention

[0004] The embodiments of the present application provide a service link verification method, system, device, equipment, and storage medium, which can improve the verification efficiency of the service link. The above technical solution is as follows: In a first aspect, an embodiment of the present application provides a service link verification method, applied to a server, comprising: Obtain verification scenario configuration information for the service link; the verification scenario configuration information for the service link is set based on the verification target; the verification scenario configuration information for the service link includes verification policy configuration information for each node to be verified in the service link; Generate a verification configuration identifier corresponding to the verification scenario based on the verification scenario configuration information of the service link; Receiving a verification scenario admission request sent by the first terminal based on the verification configuration identifier; the verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal; In response to the verification scenario admission request, adding the first terminal context information to a whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; receiving a verification request sent by a second terminal for a verification target; the verification request including second terminal context information of the second terminal; In response to the verification request, obtaining the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information; The execution result is sent to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

[0005] In one possible implementation, the verification strategy configuration information of each node to be verified in the service link includes at least one of the following: environment configuration information of the environment node in the service link, page configuration information of the page node in the service link, experimental configuration information of the experimental node in the service link, crowd configuration information of the crowd node in the service link, recall configuration information of the engine node in the service link, and delivery configuration information of the delivery node in the service link.

[0006] In one possible implementation, the first terminal context information includes a first user identifier and a first terminal identifier; according to the verification policy configuration information of each node to be verified, the first terminal context information is added to the whitelist of each node to be verified, including: according to the environment configuration information of the environment node, the first terminal identifier is added to the whitelist of the environment node; and / or according to the page configuration information of the page node, the first terminal identifier is added to the whitelist of the page node; and / or according to the experimental configuration information of the experimental node, the first user identifier is added to the whitelist of the experimental node; and / or according to the crowd configuration information of the crowd node, the first user identifier is added to the whitelist of the crowd node; and / or according to the recall configuration information of the engine node, the first user identifier is added to the whitelist of the engine node; and / or according to the delivery configuration information of the delivery node, the first user identifier is added to the whitelist of the delivery node.

[0007] In one possible implementation, the experimental configuration information of the experimental node includes the experimental identifier of the target experiment and the experimental bucket identifier of the target experimental bucket; according to the experimental configuration information of the experimental node, the first user identifier is added to the whitelist of the experimental node, including: according to the experimental identifier and the experimental bucket identifier, calling the whitelist configuration service interface of the experimental node, and adding the first user identifier to the whitelist of the target experimental bucket.

[0008] In one possible implementation, obtaining an execution result of the service link based on the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information includes: for any node to be verified, determining whether the second terminal context information matches the whitelist of any node to be verified; if so, obtaining an execution result of any node to be verified based on the verification policy configuration information of any node to be verified; and obtaining an execution result of the service link based on the execution result of any node to be verified.

[0009] In one possible implementation, after obtaining the verification scenario configuration information of the service link, the above method also includes: associating the verification policy configuration information of each node to be verified in the service link with the identifier of the verification scenario and storing them in the database to form each verification scenario configuration record.

[0010] In a possible implementation, the method further includes: in response to a reuse request for at least one verification scenario configuration record in the database, generating a corresponding verification scenario configuration identifier corresponding to the corresponding verification scenario based on the at least one verification scenario configuration record.

[0011] In a second aspect, an embodiment of the present application provides a service link verification method, applied to a first terminal, comprising: Receive a verification configuration identifier corresponding to a verification scenario sent by a server; the verification configuration identifier corresponding to the verification scenario is generated based on the verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; In response to a user triggering operation on the verification configuration identifier, generating a verification scenario admission request; the verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal; A verification scenario access request is sent to a server so that the server: receives the verification scenario access request; in response to the verification scenario access request, adds the first terminal context information to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; receives a verification request sent by the second terminal for the verification target; the verification request includes the second terminal context information of the second terminal; in response to the verification request, obtains the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified and the second terminal context information; and sends the execution result to the second terminal so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

[0012] In one possible implementation, the verification configuration identifier is a QR code; in response to a user triggering operation on the verification configuration identifier, a verification scenario access request is generated, including: in response to a user scanning operation on the QR code, a verification scenario access request is generated.

[0013] In a third aspect, an embodiment of the present application provides a service link verification system, comprising: a server, a first terminal, and a second terminal; wherein, The server is configured to obtain verification scenario configuration information of the service link, generate a verification configuration identifier corresponding to the verification scenario based on the verification scenario configuration information of the service link, and send the verification configuration identifier to the first terminal; the verification scenario configuration information of the service link is based on the verification target setting; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; The first terminal is configured to receive a verification configuration identifier sent by the server, generate a verification scenario admission request in response to a user triggering operation on the verification configuration identifier, and send the verification scenario admission request to the server; the verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal; The server is further configured to receive a verification scenario admission request sent by the first terminal based on the verification configuration identifier; in response to the verification scenario admission request, add the first terminal context information to a whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; The second terminal is configured to generate a verification request in response to a verification operation triggered by a user for a verification target, and send the verification request to a server; the verification request includes second terminal context information of the second terminal; The server is further configured to, in response to the verification request, obtain an execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the context information of the second terminal, and send the execution result to the second terminal; The second terminal is further configured to display a verification result corresponding to the verification target based on the execution result.

[0014] In a fourth aspect, an embodiment of the present application provides a service link verification device, which is applied to a server and includes: An acquisition module is used to obtain verification scenario configuration information of a service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; A generation module, configured to generate a verification configuration identifier corresponding to a verification scenario based on the verification scenario configuration information of the service link; A first receiving module is configured to receive a verification scenario admission request sent by a first terminal based on a verification configuration identifier; the verification scenario admission request includes verification scenario configuration information of a service link and first terminal context information of the first terminal; A first response module, configured to respond to the verification scenario admission request and add the first terminal context information to a whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; A second receiving module is configured to receive a verification request sent by a second terminal for a verification target; the verification request includes second terminal context information of the second terminal; A second response module is configured to respond to the verification request and obtain an execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information; The first sending module is configured to send the execution result to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

[0015] In a fifth aspect, an embodiment of the present application provides a service link verification device, which is applied to a first terminal and includes: The third receiving module is used to receive the verification configuration identifier corresponding to the verification scenario sent by the server; the verification configuration identifier corresponding to the verification scenario is generated according to the verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes the verification policy configuration information of each node to be verified in the service link; A third response module is configured to generate a verification scenario admission request in response to a user triggering operation on the verification configuration identifier; the verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal; The second sending module is used to send the verification scenario access request to the server, so that the server: receives the verification scenario access request; responds to the verification scenario access request, adds the first terminal context information to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; receives the verification request sent by the second terminal for the verification target; the verification request includes the second terminal context information of the second terminal; responds to the verification request, obtains the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified and the second terminal context information; sends the execution result to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

[0016] In a sixth aspect, an embodiment of the present application provides an electronic device comprising: a processor and a memory; the memory stores a computer program, and when the processor executes the computer program, the method steps provided in the first aspect or the second aspect of the embodiment of the present application are implemented.

[0017] In the seventh aspect, an embodiment of the present application provides a computer storage medium, which stores multiple instructions, and the instructions are suitable for being loaded by a processor and executing the method steps provided in the first aspect or the second aspect of the embodiment of the present application.

[0018] The verification method of the above-mentioned service link, on the server side: by obtaining the verification scenario configuration information of the service link, aggregating the verification policy configuration information corresponding to each node to be verified in the service link, generating a verification configuration identifier corresponding to the verification scenario, and adding the context information to the whitelist of each node to be verified according to the verification scenario access request sent by the first terminal based on the identifier, it is possible to realize the automatic configuration of the whitelist of each node; by responding to the verification request containing the context information of the second terminal, according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified and the context information of the second terminal, the execution result of the service link is obtained, and the link can be controlled at the node level based on the automatically configured whitelist. On the terminal side: a simple trigger operation is completed through the first terminal to generate a verification scenario access request containing the context information of the first terminal and the verification scenario configuration information, which effectively simplifies the user's operation process; through the second terminal, the verification result corresponding to the verification target is displayed, realizing visual feedback of the execution result of the service link.

[0019] The above-mentioned service link verification method, on the one hand, effectively simplifies the configuration process in the service link verification process by automatically configuring the whitelist of each node to be verified; on the other hand, node-level control of the link is performed through the automatically configured whitelist, which can ensure that the verification request carrying the admitted context information can stably hit the preset target logic branch in the service link, avoid the result deviation caused by the uncertainty of diversion, shorten the problem troubleshooting cycle in the service link verification process, and the verification process of the entire service link can improve the verification efficiency of the service link. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0021] Figure 1 A schematic diagram of an application scenario of a service link verification method provided by an exemplary embodiment of the present application; Figure 2 A schematic diagram of an application environment for a service link verification method provided by an exemplary embodiment of the present application; Figure 3 A flowchart of a service link verification method provided by an exemplary embodiment of the present application; Figure 4 A schematic diagram of a verification scenario configuration page provided by an exemplary embodiment of the present application; Figure 5A flowchart of another service link verification method provided by an exemplary embodiment of the present application; Figure 6 A schematic diagram of the structure of a service link verification device provided by an exemplary embodiment of the present application; Figure 7 A schematic structural diagram of another service link verification device provided by an exemplary embodiment of the present application; Figure 8 A schematic structural diagram of an electronic device provided as an exemplary embodiment of the present application; Figure 9 A schematic structural diagram of another electronic device provided as an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0023] In the description of this application, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances. In addition, in the description of this application, unless otherwise specified, "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship.

[0024] In order to more clearly describe the technical solution of the embodiment of the present application, some concepts in the present application are described in detail before the description to facilitate a better understanding of the solution.

[0025] Service link: In this solution, it refers to the complete request processing path from the terminal side to the server side.

[0026] Node to be verified: A functional module to be verified in the service link. The node to be verified can be an experimental node for functional experiments, a delivery node for content delivery, an engine node for recalling related content, etc.

[0027] Verification scenario: The service chain execution rules set for the verification target (such as service functions, service rules, etc.) ensure that the verification request hits the target logical branch by controlling the execution strategy of each node to be verified in the service chain.

[0028] The following combination Figure 1Introduce the application scenarios applicable to the embodiments of this application: A food delivery app needs to launch a new service function A. To ensure that the service function A meets expectations after launch, the execution effect of the associated service links needs to be verified before release.

[0029] See Figure 1 The verification process of the service link can be divided into: verification scenario configuration phase, verification configuration identifier generation phase, verification scenario access phase, and verification execution phase. The specific implementation process of each phase is as follows: During the verification scenario configuration phase, users (such as acceptance personnel) set the verification strategy configuration information for each node to be verified in the service chain in the backend service system of the food delivery app, including setting the following information in the service chain: environment configuration information of the environment node, page configuration information of the page node, experimental configuration information of the experimental node, crowd configuration information of the crowd node, recall configuration information of the engine node, and delivery configuration information of the delivery node.

[0030] During the verification configuration identifier generation phase, the food delivery APP's backend service system uses a QR code generator to generate a QR code corresponding to the verification scenario based on all the configuration information set above.

[0031] During the verification scenario access phase, users scan the aforementioned QR code using a terminal (such as a mobile phone) logged into the food delivery app to access the terminal information collection page. Once the user authorizes the upload of terminal context information, including the user ID in the food delivery app and the terminal's device ID, to the backend service system on the terminal information collection page, the terminal generates a verification scenario access request based on the terminal context information and the verification scenario configuration information and sends the verification scenario access request to the backend service system. The backend service system, through the verification scenario access center, invokes different service interfaces based on the verification scenario configuration information in the verification scenario access request, adding the user ID and device ID in the terminal context information to the whitelist of each node to be verified as needed, thereby ensuring that subsequent verification requests from the terminal will match the aforementioned verification scenario.

[0032] During the verification execution phase, a user triggers Service Function A through the food delivery app on their terminal (for example, by clicking on the entry for Service Function A). In response to the user's verification action for Service Function A, the terminal generates a verification request including the terminal's context information and sends it to the backend service system. Based on the terminal's context information in the verification request, the whitelist of nodes to be verified, and the verification policy configuration information for each node to be verified, the backend service system obtains the execution result of the service link and sends it to the terminal. The terminal then displays Service Function A based on the execution result for the user to compare with their expectations.

[0033] The service link verification method provided in the embodiment of the present application can be applied to Figure 2In the application environment shown. Among them, the first terminal 10 and the second terminal 20 communicate with the server 30 through the network. The first terminal 10 and the second terminal 20 are both installed with an online APP, and the online APP has completed login through a personal account. The first terminal 10 and the second terminal 20 can be the same or different. The server 30 is the background server corresponding to the online APP. The data storage system can store data that the server 30 needs to process, such as storage verification policy configuration records, etc. The data storage system can be integrated on the server 30, or it can be placed on the cloud or other network servers.

[0034] In some possible embodiments, in response to a user's verification scenario configuration operation, the server 30 obtains verification scenario configuration information for the service link, generates a verification configuration identifier corresponding to the verification scenario based on the verification scenario configuration information, and sends the verification configuration identifier to the first terminal 10. The verification scenario configuration information for the service link includes verification policy configuration information for each node to be verified in the service link. The first terminal 10 receives the verification configuration identifier sent by the server 30 and, in response to a user triggering operation on the verification configuration identifier, generates a verification scenario admission request and sends the verification scenario admission request to the server 30. The verification scenario admission request includes the verification scenario configuration information for the service link and first terminal context information of the first terminal 10. The server 30 receives the verification scenario admission request sent by the first terminal 10 based on the verification configuration identifier and, in response to the verification scenario admission request, adds the first terminal context information to the whitelist of each node to be verified based on the verification policy configuration information of each node to be verified. The second terminal 20 generates a verification request in response to a user triggering a verification operation on a verification target and sends the verification request to the server 30. The verification request includes second terminal context information of the second terminal 20. In response to the verification request, the server 30 obtains the execution result of the service link based on the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information, and sends the execution result to the second terminal 20. The second terminal 20 displays the verification result corresponding to the verification target based on the execution result.

[0035] It is understandable that the above-mentioned online apps can be, but are not limited to, e-commerce apps (such as food delivery apps), travel service apps, digital product service apps (such as e-book apps), etc. The first terminal 10 and the second terminal 20 can be, but are not limited to, various smartphones, tablets, personal computers, laptops, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The first terminal 10 and the second terminal 20 can each be implemented as a single terminal device or a terminal cluster consisting of multiple terminals. The server 30 can be implemented as an independent server or a server cluster consisting of multiple servers.

[0036] In one embodiment, Figure 3 As shown, a service link verification method is provided, which is applied to Figure 2 The following steps are described using the application environment shown as an example: S301: The server 30 obtains the authentication scenario configuration information of the service link in response to the user's authentication scenario configuration operation.

[0037] The verification scenario configuration information of the service link is based on the verification target setting. The verification scenario configuration information of the service link includes the verification strategy configuration information of each node to be verified in the service link. The verification strategy configuration information of each node to be verified in the service link includes at least one of the following: environment configuration information of the environment node in the service link, page configuration information of the page node in the service link, experiment configuration information of the experiment node in the service link, crowd configuration information of the crowd node in the service link, recall configuration information of the engine node in the service link, and delivery configuration information of the delivery node in the service link.

[0038] Specifically, the environment node in the service chain is deployed on the terminal side and is used to dynamically configure the client's operating environment on different devices. The environment configuration information includes, for example, an environment release identifier for specifying the client's operating environment. The page node in the service chain is deployed on the terminal side and is used to dynamically route to page versions adapted for different devices. The page configuration information includes, for example, a page version identifier for specifying the routed page version. The experiment node in the service chain is deployed on the server side and is used to dynamically assign users to experimental groups for experiments. The experiment configuration information includes, for example, an experiment identifier and an experiment bucket identifier for specifying the experimental group. The crowd node in the service chain is deployed on the server side and is used to simulate user demographics. The crowd configuration information includes, for example, a crowd package identifier for specifying demographics. The engine node in the service chain is deployed on the server side and is used to dynamically select a recall strategy to complete an item recall. The recall configuration information includes, for example, a recall strategy identifier for specifying the recall strategy. The delivery node in the service chain is deployed on the server side and is used to dynamically select a delivery plan to complete an item delivery. The delivery configuration information includes, for example, a delivery plan identifier for specifying the delivery plan.

[0039] For example, see Figure 4 , users can Figure 4 The verification scenario configuration page shown is used to input the verification scenario configuration operation, including inputting the verification scenario name, selecting the node to be verified, and inputting the verification strategy configuration information of each node to be verified. Specifically, after the user inputs the verification scenario name, the user can select the environment node, page node, experiment node, crowd node, engine node, and delivery node as the node to be verified, and configure the environment release ID for the environment node, the page routing version number for the page node, the experiment ID and the experiment bucket ID for the experiment node, the crowd package ID for the crowd node, the recall strategy ID for the engine node, and the delivery plan ID for the delivery node. In response to the verification scenario configuration operation input by the user based on the verification scenario configuration page, the server 30 obtains the following content as the verification scenario configuration information of the service link: the verification scenario name of the service link, the environment release ID corresponding to the environment node in the service link, the page routing version number corresponding to the page node in the service link, the experiment ID and the experiment bucket ID of the experiment node in the service link, the crowd package ID corresponding to the crowd node in the service link, the recall strategy ID corresponding to the engine node in the service link, and the delivery plan ID corresponding to the delivery node in the service link.

[0040] In this embodiment, server 30, in response to a user's verification scenario configuration operation, centrally obtains verification policy configuration information corresponding to each of the environment node, page node, experiment node, crowd node, engine node, and delivery node, thereby forming verification scenario configuration information for the entire service chain. This approach, on the one hand, facilitates the subsequent generation of a unified verification configuration identifier for the service chain based on the verification scenario configuration information, enabling automated reporting of terminal context information. On the other hand, it facilitates the subsequent automatic addition of terminal context information to the whitelist of each node to be verified based on the verification policy configuration information of each node to be verified, eliminating the need for manual node-by-node configuration. This overall process effectively improves the verification efficiency of the service chain.

[0041] S302: The server 30 generates a verification configuration identifier corresponding to the verification scenario according to the verification scenario configuration information of the service link.

[0042] The verification configuration identifier is a unique identifier generated based on the verification scenario configuration information of the service link. The terminal can obtain the verification scenario configuration information of the service link based on this unique identifier and send a verification scenario admission request containing the verification scenario configuration information and terminal context information to the server. It is understood that the verification configuration identifier can be a Uniform Resource Locator (URL), a QR code (i.e., a graphical encoding of the URL), etc.

[0043] Optionally, the server 30 generates a QR code corresponding to the verification scenario according to the verification scenario configuration information of the service link through a QR code generator. It is worth noting that the QR code contains a URL pointing to a terminal information collection page, in which the verification scenario configuration information of the service link is embedded.

[0044] In this embodiment, the server 30 generates a verification configuration identifier corresponding to the verification scenario based on the verification scenario configuration information of the service link, so that the terminal can automatically trigger the verification scenario access process based on the identifier, thereby reducing manual configuration and effectively improving the verification efficiency of the service link.

[0045] S303 : The server 30 sends the verification configuration identifier to the first terminal 10 .

[0046] Optionally, the server 30 sends the generated QR code to the first terminal 10 through a network interface.

[0047] S304 : The first terminal 10 receives the verification configuration identifier sent by the server 30 .

[0048] Optionally, the first terminal 10 receives the QR code sent by the server 30 through a network interface.

[0049] S305: The first terminal 10 generates a verification scenario admission request in response to the user's triggering operation on the verification configuration identifier.

[0050] Among them, the first terminal 10 is a terminal that triggers a verification scenario access request based on a verification configuration identifier during the verification scenario access phase. The verification scenario access request is a request triggered by the terminal based on a verification configuration identifier (such as a QR code), which is used to trigger the server to add the terminal context information to the whitelist of each node to be verified to ensure that the subsequent verification request of the terminal can hit the target logical branch corresponding to the verification scenario. In this embodiment, the verification scenario access request includes the verification scenario configuration information of the service link and the first terminal context information of the first terminal 10. The first terminal context information includes a first user identifier and a first terminal identifier. The above-mentioned first user identifier can be a personal account identifier logged in to the online APP of the first terminal 10. The above-mentioned first terminal identifier can be the device number of the first terminal 10, the system type identifier of the first terminal 10 (such as iOS, Android, etc.), the version number corresponding to the system type of the first terminal 10, etc.

[0051] Optionally, the user scans the QR code through the first terminal 10, and the first terminal 10 generates a verification scenario access request in response to the user's scanning operation on the QR code. Specifically, in the process of the first terminal 10 generating the verification scenario access request, the first terminal 10 parses the URL embedded in the QR code and jumps to the terminal information collection page; after the user authorizes on the terminal information collection page to upload terminal context information such as the user's user ID in the food delivery app and the terminal's device ID to the server, the first terminal 10 generates a verification scenario access request containing the first terminal context information and verification scenario configuration information in response to the user's information collection authorization operation.

[0052] In this embodiment, the first terminal 10 generates a verification scenario access request containing terminal context information and verification scenario configuration information in response to a simple trigger operation by the user on a verification configuration identifier (such as a QR code), which helps the server automatically add the terminal context information to the whitelist of each node to be verified based on the verification scenario access request. This not only lowers the user's operation threshold, but also simplifies the user's operation process, thereby effectively improving the verification efficiency of the service link.

[0053] S306 : The first terminal 10 sends a verification scenario admission request to the server 30 .

[0054] Optionally, the first terminal 10 sends the verification scenario admission request to the server 30 through the network interface.

[0055] S307 : The server 30 receives the verification scenario admission request sent by the first terminal 10 .

[0056] Optionally, the server 30 receives, through a network interface, a verification scenario admission request sent by the first terminal 10 based on the verification configuration representation.

[0057] S308: In response to the verification scenario admission request, the server 30 adds the first terminal context information to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified.

[0058] Optionally, in response to the verification scenario access request, the server 30 calls the service interface of each node to be verified according to the verification policy configuration information of each node to be verified in the verification scenario configuration information, and adds the first terminal context information to the whitelist of each node to be verified as needed.

[0059] Specifically, when the verification scenario configuration information includes the environment configuration information of the environment node, the server 30 calls the service interface of the environment node according to the environment configuration information of the environment node, and adds the first terminal identifier to the whitelist of the environment node to realize the logical association between the first terminal identifier and the environment release single identifier, ensuring that subsequent verification requests of the first terminal 10 can hit the specified client operating environment.

[0060] When the verification scenario configuration information includes the page configuration information of the page node, the server 30 calls the service interface of the page node according to the page configuration information of the page node, and adds the first terminal identifier to the whitelist of the page node to realize the logical association between the first terminal identifier and the page version identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified routing page version.

[0061] When the verification scenario configuration information includes the experimental configuration information of the experimental node, the server 30 calls the service interface of the experimental node according to the experimental configuration information of the experimental node, and adds the first user identifier to the whitelist of the experimental node to realize the logical association between the first user identifier and the experimental identifier and the experimental bucket identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified experimental group.

[0062] When the verification scenario configuration information includes the crowd configuration information of the crowd node, the server 30 calls the service interface of the crowd node according to the crowd configuration information of the crowd node, and adds the first user identifier to the whitelist of the crowd node to realize the logical association between the first user identifier and the crowd package identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified crowd characteristics.

[0063] When the verification scenario configuration information includes the recall configuration information of the engine node, the server 30 calls the service interface of the engine node according to the recall configuration information of the engine node, and adds the first user identifier to the whitelist of the engine node to realize the logical association between the first user identifier and the recall policy identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified recall policy.

[0064] When the verification scenario configuration information includes the delivery configuration information of the delivery node, the server 30 calls the service interface of the delivery node according to the delivery configuration information of the delivery node, and adds the first user identifier to the whitelist of the delivery node to realize the logical association between the first user identifier and the delivery plan identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified delivery plan.

[0065] In this embodiment, the server 30 responds to the verification scenario access request and automatically adds the terminal context information to the whitelist of the corresponding node according to the verification policy configuration information of each node to be verified, thereby realizing the automated configuration of the multi-node whitelist of the service link, effectively simplifying the configuration process during the service link verification process, and improving the verification efficiency of the service link.

[0066] S309: The second terminal 20 generates a verification request in response to the verification operation triggered by the user on the verification target.

[0067] The second terminal 20 is the terminal used to initiate a verification request for the verification target and display the verification result corresponding to the verification target during the verification execution phase. It is understood that the second terminal 20 and the first terminal 10 can be the same or different. In this embodiment, the verification request includes second terminal context information of the second terminal 20. The second terminal context information includes a second user identifier and a second terminal identifier. The second user identifier can be the identifier of a personal account logged in to the online app of the second terminal 20. The second terminal identifier can be the device number of the second terminal 20, the system type identifier of the second terminal 20 (such as iOS, Android, etc.), the version number corresponding to the system type of the second terminal 20, etc.

[0068] Optionally, the user triggers service function A through an online APP on the second terminal 20 (for example, clicks on the service function A entrance). In response to the verification operation triggered by the user for service function A, the second terminal 20 generates a verification request including the second terminal context information.

[0069] S310 : The second terminal 20 sends a verification request to the server 30 .

[0070] Optionally, the second terminal 20 sends a verification request to the server 30 through a network interface.

[0071] S311 : The server 30 receives the verification request sent by the second terminal 20 .

[0072] Optionally, the server 30 receives a verification request sent by the second terminal 20 for a verification target through a network interface.

[0073] S312: In response to the verification request, the server 30 obtains the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information.

[0074] Optionally, in response to the verification request, server 30 determines, for each of the nodes to be verified, whether the second terminal context information matches a whitelist of any of the nodes to be verified. If so, server 30 obtains the execution result of any of the nodes to be verified based on the verification policy configuration information of the node to be verified. If not, server 30 obtains the execution result of any of the nodes to be verified based on the dynamic diversion rules. Ultimately, server 30 obtains the execution result of the service link based on the execution result of each node to be verified in the service link.

[0075] In this embodiment, the server 30 ensures that the verification request carrying the access context information (the first terminal context information in this embodiment) can stably hit the preset target strategy in the service link through node-level control based on the whitelist mechanism, avoiding result deviations caused by diversion uncertainty, shortening the problem troubleshooting cycle in the service link verification process, and thus improving the verification efficiency of the service link.

[0076] S313 : The server 30 sends the execution result to the second terminal 20 .

[0077] Optionally, the server 30 sends the execution result to the second terminal 20 through a network interface.

[0078] S314 : The second terminal 20 receives the execution result sent by the server 30 .

[0079] Optionally, the second terminal 20 receives the execution result sent by the server 30 through a network interface.

[0080] S315: The second terminal 20 displays the verification result corresponding to the verification target based on the execution result.

[0081] Optionally, the execution result of the service link includes specific service data and a link status identifier of the service link. The specific service data may include a template identifier of a page rendering template, fill data of the page rendering template, a recommended content set, etc. The link status identifier of the service link may include the verification policy identifier (e.g., experiment identifier, experiment bucket identifier) ​​currently being executed by each node to be verified in the service link.

[0082] Exemplarily, assuming that the verification target is a certain activity rule, the server 30 sends the execution result including the template identifier of the page rendering template, the fill data of the page rendering template, the recommended content set, the experiment identifier currently executed by the service link, and the experiment bucket identifier to the second terminal 20. The second terminal 20 can render the corresponding activity page in the online APP it runs based on the execution result; at the same time, the second terminal 20 can generate debugging information based on the verification policy identifier currently executed by each of the above-mentioned nodes to be verified and the verification policy identifier pre-configured by the user at each node to be verified, and display it in the form of a floating layer or log, so that the user can confirm whether the activity rule is effective as expected.

[0083] In this embodiment, the second terminal 20 displays the verification result page corresponding to the verification target in the online app based on the execution result, which includes service data and link status identifiers. This provides visual feedback on the service link execution results and provides users with the necessary link verification evidence. This approach allows users to visually confirm the effectiveness of the verification target by viewing the page content, enhancing the perceptibility and credibility of the verification process. Furthermore, the terminal can automatically parse the link status identifier and determine the policy hit status of each key node, further automating the verification process. The entire process effectively improves the efficiency of service link verification.

[0084] In the above-mentioned service link verification method, on the server side: by obtaining the verification scenario configuration information of the service link, aggregating the verification policy configuration information corresponding to each node to be verified in the service link, generating a verification configuration identifier corresponding to the verification scenario, and according to the verification scenario access request sent by the first terminal based on the identifier, adding the context information to the whitelist of each node to be verified, it is possible to realize the automatic configuration of the whitelist of each node; by responding to the verification request sent by the second terminal, according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified and the context information of the second terminal, obtaining the execution result of the service link, it is possible to perform node-level control of the link based on the automatically configured whitelist. On the terminal side: a simple trigger operation is completed through the first terminal to generate a verification scenario access request containing the first terminal context information and the verification scenario configuration information, which effectively simplifies the user's operation process; through the second terminal, a verification request containing the second terminal context information is sent to the server to display the verification result corresponding to the verification target, realizing visual feedback of the service link execution result.

[0085] The above-mentioned service link verification method, on the one hand, effectively simplifies the configuration process in the service link verification process by automatically configuring the whitelist of each node to be verified; on the other hand, the link is controlled at the node level through the automatically configured whitelist, ensuring that the verification request carrying the allowed context information can stably hit the preset target logic branch in the service link, avoiding the result deviation caused by the uncertainty of the diversion, thereby shortening the problem troubleshooting cycle in the service link verification process. The verification process of the entire service link can effectively improve the verification efficiency of the service link.

[0086] In one embodiment, Figure 5 As shown, another service link verification method is provided, which is applied to Figure 2 The server 30 is used as an example for description, and the following steps are included: S501: In response to a user's verification scenario configuration operation, obtain verification scenario configuration information of a service link.

[0087] The verification scenario configuration information for the service link is based on the verification target setting. The verification scenario configuration information for the service link includes the verification strategy configuration information for each node to be verified in the service link. The verification strategy configuration information for each node to be verified in the service link includes: environment configuration information for the environment node in the service link, page configuration information for the page node in the service link, experiment configuration information for the experiment node in the service link, crowd configuration information for the crowd node in the service link, recall configuration information for the engine node in the service link, and delivery configuration information for the delivery node in the service link.

[0088] For details, please refer to the above S301, which will not be repeated here.

[0089] S502: The verification policy configuration information of each node to be verified in the service link is associated with the identifier of the verification scenario and stored in the database to form each verification policy configuration record.

[0090] Optionally, after obtaining the verification scenario configuration information of the service link, the server 30 stores each piece of verification policy configuration information in the database to form each verification policy configuration record.

[0091] Exemplarily, the server 30 associates the environment configuration information of the environment node (such as the environment release order ID, etc.), the page configuration information of the page node (such as the page routing version number, etc.), the experimental configuration information of the experimental node (such as the experiment ID, the experimental bucket ID, etc.), the crowd configuration information of the crowd node (such as the crowd package ID, etc.), the recall configuration information of the engine node (such as the recall strategy ID, etc.), and the delivery configuration information of the delivery node (such as the delivery plan ID, etc.) with the name of the verification scenario and stores them in the database to form six verification strategy configuration records, which are convenient for subsequent tracing and reuse.

[0092] In this embodiment, the server 30 associates each verification policy configuration information in the verification scenario configuration information with the verification scenario configuration identifier and stores it in the database. This not only facilitates the subsequent backtracking of the specific configuration parameters corresponding to the verification scenario based on the verification scenario configuration identifier, but also facilitates the subsequent flexible reuse of these verification policy configuration records to regenerate the verification configuration identifier, thereby improving the traceability and efficiency of service link verification.

[0093] S503: Generate a verification configuration identifier corresponding to the verification scenario according to the verification scenario configuration information of the service link.

[0094] For details, please refer to the above S302, which will not be repeated here.

[0095] S504: Receive a verification scenario admission request sent by the first terminal based on the verification configuration identifier.

[0096] The verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal.

[0097] S505: In response to the verification scenario admission request, the first terminal identifier is added to a whitelist of the environment node according to the environment configuration information of the environment node.

[0098] Optionally, the server 30 responds to the verification scenario access request and, based on the environment configuration information of the environment node, calls the whitelist configuration service interface of the environment node to add the first terminal identifier to the whitelist of the environment node to achieve a logical association between the first terminal identifier and the environment release single identifier, ensuring that subsequent verification requests from the first terminal 10 can hit the specified client operating environment.

[0099] S506: Add the first terminal identifier to the whitelist of the page node according to the page configuration information of the page node.

[0100] Optionally, the server 30 calls the whitelist configuration service interface of the page node based on the page configuration information of the page node, and adds the first terminal identifier to the whitelist of the page node to realize the logical association between the first terminal identifier and the page version identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified routing page version.

[0101] S507: Add the first user identifier to the whitelist of the experimental node according to the experimental configuration information of the experimental node.

[0102] Optionally, the server 30 calls the whitelist configuration service interface of the experimental node according to the experimental configuration information of the experimental node, and adds the first user identifier to the whitelist of the experimental node to realize the logical association between the first user identifier and the experimental identifier and the experimental bucket identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified experimental group.

[0103] Specifically, the experimental configuration information of the experimental node includes the experiment identifier of the target experiment and the experiment bucket identifier of the target experiment bucket. Based on the experiment identifier and the experiment bucket identifier, server 30 can call the whitelist configuration service interface of the experimental node to add the first user identifier to the whitelist of the target experiment bucket. When subsequently processing a verification request containing the first user identifier, server 30 will execute the experimental policy for the specified experimental group at the experimental node.

[0104] In addition, the server can also call the whitelist configuration service interface of the experimental node based only on the experiment identifier, and add the first user identifier to the whitelist of the target experiment bucket. When subsequently processing the verification request containing the first user identifier, the server 30 will traverse and execute the experimental strategy of each experimental group corresponding to the experiment at the experimental node, and return the currently executed experiment identifier and experiment bucket identifier to the second terminal, so that the second terminal can display the currently executed experiment identifier and experiment bucket identifier in real time in the form of a floating layer or log while displaying the verification result.

[0105] In this embodiment, server 30 establishes a logical association between the first user identifier, the experiment identifier, and the experiment bucket identifier by calling the whitelist configuration service interface of the experimental node. This ensures that subsequent verification requests from the first terminal can stably hit the specified experimental group, avoiding the path uncertainty problem caused by random diversion of natural traffic and ensuring the accuracy of functional experimental verification. In addition, server 30 also supports whitelist configuration at the experimental node based solely on the experiment identifier and traverses and executes the policy logic of all experimental groups under the experiment when processing verification requests, so that a single verification can cover multiple branch logics, effectively improving verification coverage and verification efficiency.

[0106] S508: Add the first user identifier to the whitelist of the crowd node according to the crowd configuration information of the crowd node.

[0107] Optionally, the server 30 calls the whitelist configuration service interface of the crowd node based on the crowd configuration information of the crowd node, and adds the first user identifier to the whitelist of the crowd node to achieve a logical association between the first user identifier and the crowd package identifier, ensuring that subsequent verification requests from the first terminal 10 can hit the specified crowd characteristics.

[0108] S509: Add the first user identifier to the whitelist of the engine node according to the recall configuration information of the engine node.

[0109] Optionally, the server 30 calls the whitelist configuration service interface of the engine node according to the recall configuration information of the engine node, and adds the first user identifier to the whitelist of the engine node to realize the logical association between the first user identifier and the recall policy identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified recall policy.

[0110] S510: Add the first user identifier to the whitelist of the delivery node according to the delivery configuration information of the delivery node.

[0111] Optionally, the server 30 calls the whitelist service interface of the delivery node according to the delivery configuration information of the delivery node, and adds the first user identifier to the whitelist of the delivery node to realize the logical association between the first user identifier and the delivery plan identifier, thereby ensuring that subsequent verification requests of the first terminal 10 can hit the specified delivery plan.

[0112] S511: Receive a verification request sent by a second terminal for a verification target.

[0113] The verification request includes second terminal context information of the second terminal.

[0114] S512: In response to the verification request, obtain the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information.

[0115] Optionally, in response to the verification request, the server 30 determines, for any of the nodes to be verified, according to the verification policy configuration information of any of the nodes to be verified, whether the second terminal context information matches a whitelist of any of the nodes to be verified.

[0116] For example, for an experimental node in a service link, server 30 determines whether the second user identifier in the second terminal's context information matches the first user identifier in the experimental node's whitelist based on the experimental node's verification policy configuration information. If they match, server 30 retrieves the execution result of the experimental node based on the verification policy configuration information of any node to be verified. If they do not match, server 30 retrieves the execution result of the experimental node based on the dynamic diversion rules. Ultimately, server 30 retrieves the execution result of the entire link based on the execution results of each node to be verified in the service link.

[0117] In this embodiment, the server 30 determines whether the second context information in the verification request is consistent with the information in the whitelist of each node to be verified through node-level control based on the whitelist mechanism, thereby ensuring that the verification request carrying the approved context information can stably hit the preset target strategy in the service link, avoiding result deviations caused by diversion uncertainty, thereby shortening the problem troubleshooting cycle in the service link verification process and improving the verification efficiency of the service link.

[0118] S513: In response to a reuse request for at least one verification policy configuration record in the database, generate a corresponding verification scenario configuration identifier corresponding to the corresponding verification scenario based on the at least one verification policy configuration record.

[0119] Optionally, after completing verification of the service link for a certain verification scenario, when setting new verification scenario configuration information, the user may also send a reuse request for at least one verification policy configuration record in the database to the server 30 through the terminal. After receiving the reuse request, the server 30 may generate a corresponding verification scenario configuration identifier corresponding to the new verification scenario based on the at least one reused verification policy configuration record and the verification policy configuration information newly set by the user.

[0120] In this embodiment, the server 30 generates a new verification scenario configuration identifier based on the existing record in response to a reuse request for an existing verification policy configuration record in the database, thereby achieving flexible reuse of the verification configuration and efficient generation of the verification configuration identifier, avoiding the user's repeated manual input of the same or similar verification policies during the configuration process, reducing the user's configuration workload, and improving the verification efficiency of the service link.

[0121] In the above-mentioned service link verification method, on the one hand, by calling the whitelist configuration interface of each node to be verified according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified is automatically configured, thereby effectively simplifying the configuration process in the service link verification process; on the other hand, by associating each verification policy configuration information in the verification scenario configuration information with the verification scenario configuration identifier and storing it in the database, it is convenient for subsequent backtracking and reuse of existing verification policy configuration records; on the other hand, by responding to the reuse request for the existing verification policy configuration record in the database, a new verification scenario configuration identifier is generated based on the existing record, thereby realizing flexible reuse of verification configuration and efficient generation of verification configuration identifier, avoiding the user from repeatedly manually entering the same or similar verification policies during the configuration process, and the whole process effectively improves the accuracy, flexibility, traceability and efficiency of service link verification.

[0122] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0123] Based on the inventive concept of the verification method of the above service link, Figure 8 As shown, the embodiment of the present application further provides a service link verification device 600 for implementing the above-mentioned service link verification method applied to the server. The service link verification device 600 includes: Acquisition module 601 is used to obtain verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; A generating module 602 is configured to generate a verification configuration identifier corresponding to a verification scenario according to the verification scenario configuration information of the service link; The first receiving module 603 is configured to receive a verification scenario admission request sent by the first terminal based on the verification configuration identifier; the verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal; A first response module 604 is configured to respond to the verification scenario admission request and add the first terminal context information to a whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; The second receiving module 605 is configured to receive a verification request sent by a second terminal for a verification target; the verification request includes second terminal context information of the second terminal; The second response module 606 is configured to respond to the verification request and obtain the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information; The first sending module 607 is configured to send the execution result to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

[0124] In one embodiment, the verification strategy configuration information of each node to be verified in the service link includes at least one of the following: environment configuration information of the environment node in the service link, page configuration information of the page node in the service link, experimental configuration information of the experimental node in the service link, crowd configuration information of the crowd node in the service link, recall configuration information of the engine node in the service link, and delivery configuration information of the delivery node in the service link.

[0125] In one embodiment, the first terminal context information includes a first user identifier and a first terminal identifier; the first response module 604 is specifically used to: add the first terminal identifier to the whitelist of the environment node according to the environment configuration information of the environment node; and / or add the first terminal identifier to the whitelist of the page node according to the page configuration information of the page node; and / or add the first user identifier to the whitelist of the experimental node according to the experimental configuration information of the experimental node; and / or add the first user identifier to the whitelist of the crowd node according to the crowd configuration information of the crowd node; and / or add the first user identifier to the whitelist of the engine node according to the recall configuration information of the engine node; and / or add the first user identifier to the whitelist of the delivery node according to the delivery configuration information of the delivery node.

[0126] In one embodiment, the experimental configuration information of the experimental node includes the experimental identifier of the target experiment and the experimental bucket identifier of the target experimental bucket; the first response module 604 is specifically used to: call the whitelist configuration service interface of the experimental node according to the experimental identifier and the experimental bucket identifier, and add the first user identifier to the whitelist of the target experimental bucket.

[0127] In one embodiment, the second response module 606 is specifically used to: for any node to be verified among the nodes to be verified, determine whether the second terminal context information hits the whitelist of any node to be verified; if so, obtain the execution result of any node to be verified based on the verification policy configuration information of any node to be verified; and obtain the execution result of the service link based on the execution result of any node to be verified.

[0128] In one embodiment, the service link verification device 600 further includes a data storage module for storing the verification policy configuration information of each node to be verified in the service link in association with the identification of the verification scenario in a database to form each verification scenario configuration record.

[0129] In one embodiment, the service link verification device 600 further includes a data multiplexing module for generating a corresponding verification scenario configuration identifier corresponding to a corresponding verification scenario based on at least one verification scenario configuration record in response to a multiplexing request for at least one verification scenario configuration record in a database.

[0130] Based on the inventive concept of the verification method of the above service link, Figure 7 As shown, the embodiment of the present application further provides a service link verification device 700 for implementing the above-mentioned service link verification method applied to the first terminal. The service link verification device 700 includes: The third receiving module 701 is used to receive the verification configuration identifier corresponding to the verification scenario sent by the server; the verification configuration identifier corresponding to the verification scenario is generated according to the verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes the verification policy configuration information of each node to be verified in the service link; The third response module 702 is configured to generate a verification scenario admission request in response to a user triggering operation on the verification configuration identifier; the verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal; The second sending module 703 is used to send the verification scenario access request to the server so that the server: receives the verification scenario access request; responds to the verification scenario access request, adds the first terminal context information to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; receives the verification request sent by the second terminal for the verification target; the verification request includes the second terminal context information of the second terminal; responds to the verification request, obtains the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified and the second terminal context information; sends the execution result to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

[0131] In one embodiment, the verification configuration identifier is a QR code; the third response module 702 is specifically configured to generate a verification scenario admission request in response to a user scanning operation on the QR code.

[0132] Each module in the service link verification device 600 and the service link verification device 700 can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0133] The embodiment of the present application also provides an electronic device, which may be a server, and its internal structure diagram may be as shown in FIG. Figure 8 See Figure 8The electronic device includes a processor, a memory, an input / output interface (I / O) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the electronic device is used to store verification scenario configuration records, etc. The input / output interface of the electronic device is used to exchange information between the processor and an external device. The communication interface of the electronic device is used to communicate with an external terminal via a network connection. The processor of the electronic device executes a computer program to implement a service link verification method.

[0134] It is worth noting that the electronic device can also be a terminal, and its internal structure diagram can be as follows: Figure 9 See Figure 9 The electronic device includes a processor, memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are connected to the system bus via the input / output interface. The processor of the electronic device provides computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operating system and computer programs stored in the non-volatile storage medium. The input / output interface of the electronic device is used to exchange information between the processor and external devices. The communication interface of the electronic device is used to communicate with external terminals via wired or wireless communication, which can be achieved via Wi-Fi, a mobile cellular network, NFC (near-field communication), or other technologies. When executed by the processor, the computer program implements a service link verification method. The display unit of the electronic device is used to produce a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the electronic device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the electronic device casing, or an external keyboard, touchpad or mouse.

[0135] The present application also provides a computer storage medium having instructions stored therein that, when executed on a computer or processor, cause the computer or processor to perform one or more steps of the above-described embodiments. If the components of the electronic device described above are implemented as software functional units and sold or used as independent products, they may be stored in the computer-readable storage medium described above.

[0136] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer storage medium or transmitted via the computer storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer storage medium may be any available medium accessible by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state drive (SSD)).

[0137] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When executed, the program can include the processes of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks. The technical features of this embodiment and the implementation scheme can be combined in any manner unless they conflict.

[0138] The embodiments described above are merely preferred embodiments of the present application and are not intended to limit the scope of the present application. Without departing from the design spirit of the present application, various modifications and improvements made to the technical solutions of the present application by ordinary technicians in this field should fall within the scope of protection determined by the claims.

[0139] It should be noted that the technical solution of the present application can be applied to transactions and delivery services of instant e-commerce platforms, such as Taobao flash sales, Taoxianda, Ele.me takeout and retail, etc. The information, data and signals involved in the embodiments of the present application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions. For example, the "first terminal context information", "second terminal context information" and "first user identification", "first terminal identification", "second user identification", "second terminal identification" and so on involved in this specification are all obtained with full authorization.

[0140] The foregoing description describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A service link verification method, characterized in that: Applied to a server, the method includes: Acquire verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; Generate a verification configuration identifier corresponding to the verification scenario according to the verification scenario configuration information of the service link; Receiving a verification scenario admission request sent by the first terminal based on the verification configuration identifier; the verification scenario admission request includes the verification scenario configuration information of the service link and the first terminal context information of the first terminal; In response to the verification scenario admission request, adding the first terminal context information to a whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; receiving a verification request sent by a second terminal for the verification target; the verification request including second terminal context information of the second terminal; In response to the verification request, obtaining an execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information; The execution result is sent to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

2. The method according to claim 1, wherein The verification strategy configuration information of each node to be verified in the service link includes at least one of the following: environment configuration information of the environment node in the service link, page configuration information of the page node in the service link, experimental configuration information of the experimental node in the service link, crowd configuration information of the crowd node in the service link, recall configuration information of the engine node in the service link, and delivery configuration information of the delivery node in the service link.

3. The method according to claim 2, wherein The first terminal context information includes a first user identifier and a first terminal identifier; The adding the first terminal context information to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified includes: Adding the first terminal identifier to a whitelist of the environment node according to the environment configuration information of the environment node; and / or According to the page configuration information of the page node, the first terminal identifier is added to the whitelist of the page node; and / or Adding the first user identifier to a whitelist of the experimental node according to the experimental configuration information of the experimental node; and / or adding the first user identifier to a whitelist of the crowd node according to the crowd configuration information of the crowd node; and / or adding the first user identifier to a whitelist of the engine node according to the recall configuration information of the engine node; and / or According to the delivery configuration information of the delivery node, the first user identifier is added to the whitelist of the delivery node.

4. The method according to claim 3, wherein The experiment configuration information of the experiment node includes the experiment identifier of the target experiment and the experiment bucket identifier of the target experiment bucket; The adding the first user identifier to the whitelist of the experimental node according to the experimental configuration information of the experimental node includes: According to the experiment identifier and the experiment bucket identifier, the whitelist configuration service interface of the experiment node is called to add the first user identifier to the whitelist of the target experiment bucket.

5. The method according to claim 1, wherein The acquiring, according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information, an execution result of the service link includes: For any of the nodes to be verified, determining whether the second terminal context information matches a whitelist of the node to be verified; If yes, obtaining the execution result of any node to be verified according to the verification policy configuration information of any node to be verified; The execution result of the service link is obtained according to the execution result of any node to be verified.

6. The method according to claim 1, wherein After obtaining the verification scenario configuration information of the service link, the method further includes: The verification policy configuration information of each node to be verified in the service link is associated with the identifier of the verification scenario and stored in the database to form each verification policy configuration record.

7. The method according to claim 6, wherein The method further comprises: In response to a reuse request for at least one verification policy configuration record in the database, a corresponding verification scenario configuration identifier corresponding to the corresponding verification scenario is generated based on the at least one verification policy configuration record.

8. A service link verification method, characterized in that: Applied to a first terminal, the method includes: Receiving a verification configuration identifier corresponding to a verification scenario sent by a server; the verification configuration identifier corresponding to the verification scenario is generated based on the verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; In response to a user triggering operation on the verification configuration identifier, generating a verification scenario admission request; the verification scenario admission request includes the verification scenario configuration information of the service link and the first terminal context information of the first terminal; The verification scenario access request is sent to the server so that the server: receives the verification scenario access request; in response to the verification scenario access request, adds the first terminal context information to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; receives a verification request sent by a second terminal for the verification target; the verification request includes the second terminal context information of the second terminal; in response to the verification request, obtains the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified and the second terminal context information; and sends the execution result to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

9. The method according to claim 8, wherein The verification configuration identifier is a QR code; The generating of the verification scenario admission request in response to the user's triggering operation on the verification configuration identifier includes: In response to the user's scanning operation on the QR code, a verification scene admission request is generated.

10. A service link verification system, characterized in that: The service link verification system includes: a server, a first terminal and a second terminal; wherein, The server is configured to obtain verification scenario configuration information of the service link, generate a verification configuration identifier corresponding to the verification scenario based on the verification scenario configuration information of the service link, and send the verification configuration identifier to the first terminal; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; The first terminal is configured to receive a verification configuration identifier sent by the server, generate a verification scenario admission request in response to a user triggering operation on the verification configuration identifier, and send the verification scenario admission request to the server; the verification scenario admission request includes verification scenario configuration information of the service link and first terminal context information of the first terminal; The server is further configured to receive a verification scenario admission request sent by the first terminal based on the verification configuration identifier; in response to the verification scenario admission request, add the first terminal context information to a whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; The second terminal is configured to generate a verification request in response to a verification operation triggered by a user on the verification target, and send the verification request to the server; the verification request includes second terminal context information of the second terminal; The server is further configured to, in response to the verification request, obtain an execution result of the service link based on the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the context information of the second terminal, and send the execution result to the second terminal; The second terminal is further configured to display a verification result corresponding to the verification target based on the execution result.

11. A service link verification device, characterized in that: Applied to a server, the device includes: An acquisition module, configured to acquire verification scenario configuration information of a service link; the verification scenario configuration information of the service link is set based on a verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; A generation module, configured to generate a verification configuration identifier corresponding to a verification scenario according to the verification scenario configuration information of the service link; A first receiving module is configured to receive a verification scenario admission request sent by a first terminal based on the verification configuration identifier; the verification scenario admission request includes the verification scenario configuration information of the service link and the first terminal context information of the first terminal; A first response module, configured to respond to the verification scenario admission request and, based on the verification policy configuration information of each node to be verified, add the first terminal context information to a whitelist of each node to be verified; A second receiving module is configured to receive a verification request sent by a second terminal for the verification target; the verification request includes second terminal context information of the second terminal; a second response module, configured to, in response to the verification request, obtain an execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified, and the second terminal context information; The first sending module is configured to send the execution result to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

12. A service link verification device, characterized in that: Applied to a first terminal, the apparatus includes: A third receiving module is configured to receive a verification configuration identifier corresponding to a verification scenario sent by a server; the verification configuration identifier corresponding to the verification scenario is generated based on the verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on the verification target; the verification scenario configuration information of the service link includes verification policy configuration information of each node to be verified in the service link; A third response module is configured to generate a verification scenario admission request in response to a user triggering operation on the verification configuration identifier; the verification scenario admission request includes the verification scenario configuration information of the service link and the first terminal context information of the first terminal; The second sending module is used to send the verification scenario access request to the server, so that the server: receives the verification scenario access request; in response to the verification scenario access request, adds the first terminal context information to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified; receives a verification request sent by the second terminal for the verification target; the verification request includes the second terminal context information of the second terminal; in response to the verification request, obtains the execution result of the service link according to the verification policy configuration information of each node to be verified, the whitelist of each node to be verified and the second terminal context information; sends the execution result to the second terminal, so that the second terminal displays the verification result corresponding to the verification target based on the execution result.

13. An electronic device, characterized in that: include: A processor and a memory; the memory stores a computer program, and when the processor executes the computer program, the method steps of any one of claims 1 to 9 are implemented.

14. A computer storage medium, characterized in that The computer storage medium stores a plurality of instructions, which are suitable for being loaded by a processor and executing the method steps according to any one of claims 1 to 9.

Images