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

Abstract

The application discloses a service link verification method, system, device, equipment and storage medium, which can improve the verification efficiency of the service link. The method comprises the following steps: obtaining verification scene configuration information of the service link; generating a verification configuration identifier corresponding to a verification scene according to the verification scene configuration information of the service link; receiving a verification scene access request sent by a first terminal based on the verification configuration identifier; in response to the verification scene access request, adding first terminal context information to the 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 to a 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 second terminal context information; 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 technical field of link verification, in particular to a service link verification method, system, device, equipment and storage medium. BACKGROUND

[0002] In software development and product iteration, test acceptance is a key link to ensure that the service link meets the expectations. Due to the complexity of the service link, in the link verification process, the dynamic shunting rule often makes the automatic use case unable to hit the specified logical branch. For example, there are A and B versions of a page, and the B version of the page effect needs to be verified through an automatic use case, but the system may route the test account to the A version based on the dynamic shunting rule (such as user feature-based shunting), and the logical branch of the B version is not executed, resulting in link verification failure.

[0003] In related technologies, by manually configuring a whitelist at each key node of the service link, it is ensured that the specific logical branch of the service link can be triggered correctly, thereby realizing the verification of the execution effect of the service link. However, this verification method is not only tedious to operate, but also easily causes the problem of misconfiguration and missing configuration of the whitelist to prolong the problem troubleshooting period, and there is a problem of low service link verification efficiency. SUMMARY

[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:

[0005] In a first aspect, the embodiments of the present application provide a service link verification method applied to a server, comprising:

[0006] Obtaining verification scenario configuration information of the 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 strategy configuration information of each to-be-verified node in the service link;

[0007] Generating a verification configuration identifier corresponding to the verification scenario according to the verification scenario configuration information of the service link;

[0008] Receiving a verification scenario access request sent by a first terminal based on the verification configuration identifier; the verification scenario access request includes the verification scenario configuration information of the service link and first terminal context information of the first terminal;

[0009] In response to the verification scenario access request, adding the first terminal context information to the whitelist of each to-be-verified node according to the verification strategy configuration information of each to-be-verified node;

[0010] Receiving a verification request sent by a second terminal for the verification target; the verification request includes second terminal context information of the second terminal;

[0011] In response to the verification request, the execution result of the service link is obtained according to the verification policy configuration information of each to-be-verified node, the white list of each to-be-verified node, and the second terminal context information;

[0012] 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.

[0013] In a possible implementation, the verification policy configuration information of each to-be-verified node in the service link includes at least one of the following: environment configuration information of an environment node in the service link, page configuration information of a page node in the service link, experiment configuration information of an experiment node in the service link, crowd configuration information of a crowd node in the service link, recall configuration information of an engine node in the service link, and delivery configuration information of a delivery node in the service link.

[0014] In a possible implementation, the first terminal context information includes a first user identifier and a first terminal identifier; and adding the first terminal context information to the white list of each to-be-verified node according to the verification policy configuration information of each to-be-verified node includes: adding the first terminal identifier to the white list of the environment node according to the environment configuration information of the environment node; and / or adding the first terminal identifier to the white list of the page node according to the page configuration information of the page node; and / or adding the first user identifier to the white list of the experiment node according to the experiment configuration information of the experiment node; and / or adding the first user identifier to the white list of the crowd node according to the crowd configuration information of the crowd node; and / or adding the first user identifier to the white list of the engine node according to the recall configuration information of the engine node; and / or adding the first user identifier to the white list of the delivery node according to the delivery configuration information of the delivery node.

[0015] In a possible implementation, the experiment configuration information of the experiment node includes an experiment identifier of a target experiment and an experiment bucket identifier of a target experiment bucket; and adding the first user identifier to the white list of the experiment node according to the experiment configuration information of the experiment node includes: calling a white list configuration service interface of the experiment node according to the experiment identifier and the experiment bucket identifier, and adding the first user identifier to the white list of the target experiment bucket.

[0016] In a possible implementation, the execution result of the service link is obtained according to the verification policy configuration information of each to-be-verified node, the white list of each to-be-verified node, and the second terminal context information, including: for any to-be-verified node in each to-be-verified node, judging whether the second terminal context information hits the white list of any to-be-verified node; if yes, the execution result of any to-be-verified node is obtained according to the verification policy configuration information of any to-be-verified node; and the execution result of the service link is obtained according to the execution result of any to-be-verified node.

[0017] In a possible implementation, after obtaining the verification scenario configuration information of the service link, the method further includes: storing the verification policy configuration information of each to-be-verified node in the service link in association with the identifier of the verification scenario in the database respectively to form each verification scenario configuration record.

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

[0019] In a second aspect, an embodiment of the present application provides a verification method of a service link, applied to a first terminal, and including:

[0020] 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 according to verification scenario configuration information of the service link; the verification scenario configuration information of the service link is set based on a verification target; and the verification scenario configuration information of the service link includes verification policy configuration information of each to-be-verified node in the service link;

[0021] generating a verification scenario access request in response to a triggering operation of a user on the verification configuration identifier; the verification scenario access request includes the verification scenario configuration information of the service link and first terminal context information of the first terminal;

[0022] sending the verification scenario access request to the server, so that the server: receives the verification scenario access request; adds the first terminal context information to a white list of each to-be-verified node according to the verification policy configuration information of each to-be-verified node in response to the verification scenario access request; receives a verification request sent by a second terminal to the verification target; the verification request includes second terminal context information of the second terminal; obtains an execution result of the service link according to the verification policy configuration information of each to-be-verified node, the white list of each to-be-verified node, and the second terminal context information in response to the verification request; and sends 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.

[0023] In a possible implementation, the verification configuration identifier is a two-dimensional code; and generating the verification scenario access request in response to the triggering operation of the user on the verification configuration identifier includes: generating the verification scenario access request in response to a scanning operation of the user on the two-dimensional code.

[0024] In a third aspect, an embodiment of the present application provides a verification system of a service link, including: a server, a first terminal, and a second terminal; and wherein,

[0025] The server is configured to acquire verification scenario configuration information of a service link, generate verification configuration identification corresponding to a verification scenario according to the verification scenario configuration information of the service link, and send the verification configuration identification to the first terminal. 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.

[0026] The first terminal is configured to receive the verification configuration identification sent by the server, generate a verification scenario access request in response to a trigger operation of a user on the verification configuration identification, and send the verification scenario access request to the server. The verification scenario access request includes the verification scenario configuration information of the service link and first terminal context information of the first terminal.

[0027] The server is further configured to receive the verification scenario access request sent by the first terminal based on the verification configuration identification, and add the first terminal context information to a white list of each node to be verified according to the verification policy configuration information of each node to be verified in response to the verification scenario access request.

[0028] The second terminal is configured to generate a verification request in response to a verification operation triggered by a user on a verification target, and send the verification request to the server. The verification request includes second terminal context information of the second terminal.

[0029] The server is further configured to acquire an execution result of the service link according to the verification policy configuration information of each node to be verified, the white list of each node to be verified, and the second terminal context information in response to the verification request, and send the execution result to the second terminal.

[0030] The second terminal is further configured to display a verification result corresponding to the verification target based on the execution result.

[0031] In a fourth aspect, an embodiment of the present application provides a verification device of a service link, applied to a server, and including:

[0032] The acquisition module is 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.

[0033] The generation module is configured to generate verification configuration identification corresponding to a verification scenario according to the verification scenario configuration information of the service link.

[0034] The first receiving module is configured to receive a verification scenario access request sent by the first terminal based on the verification configuration identification. The verification scenario access request includes the verification scenario configuration information of the service link and first terminal context information of the first terminal.

[0035] The first response module is configured to, in response to the access request of the verification scene, add the first terminal context information to the whitelist of each to-be-verified node according to the verification policy configuration information of each to-be-verified node.

[0036] The second receiving module is configured to receive a verification request sent by the second terminal for the verification target, wherein the verification request comprises second terminal context information of the second terminal.

[0037] The second response module is 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 to-be-verified node, the whitelist of each to-be-verified node, and the second terminal context information.

[0038] The first sending module is configured to send 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.

[0039] In a fifth aspect, an embodiment of the present application provides a verification device of a service link, applied to a first terminal, comprising:

[0040] The third receiving module is configured to receive a verification configuration identifier corresponding to a verification scene sent by a server, wherein the verification configuration identifier corresponding to the verification scene is generated according to verification scene configuration information of the service link, the verification scene configuration information of the service link is set based on a verification target, and the verification scene configuration information of the service link comprises verification policy configuration information of each to-be-verified node in the service link.

[0041] The third response module is configured to, in response to a triggering operation of a user for the verification configuration identifier, generate an access request of the verification scene, wherein the access request of the verification scene comprises the verification scene configuration information of the service link and first terminal context information of the first terminal.

[0042] The second sending module is configured to send the access request of the verification scene to the server, so that the server: receives the access request of the verification scene; in response to the access request of the verification scene, adds the first terminal context information to the whitelist of each to-be-verified node according to the verification policy configuration information of each to-be-verified node; receives a verification request sent by the second terminal for the verification target, wherein the verification request comprises second terminal context information of the second terminal; in response to the verification request, obtains an execution result of the service link according to the verification policy configuration information of each to-be-verified node, the whitelist of each to-be-verified node, and the second terminal context information; and sends 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.

[0043] In a sixth aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory, wherein the memory stores a computer program, and the processor implements the method steps of the first aspect or the second aspect provided by the embodiment of the present application when executing the computer program.

[0044] In a seventh aspect, the embodiments of the present application provide a computer storage medium, which stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and performing the method steps provided in the first aspect or the second aspect of the embodiments of the present application.

[0045] The verification method of the service link can achieve automatic configuration of the white lists of the nodes on the server side by obtaining the verification scenario configuration information of the service link, aggregating the verification policy configuration information corresponding to each to-be-verified node in the service link, generating a verification configuration identifier corresponding to the verification scenario, and adding context information to the white list of each to-be-verified node according to the verification scenario access request sent by the first terminal based on the identifier. The method can achieve node-level control of the link based on the automatically configured white list by obtaining the execution result of the service link according to the verification policy 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 in response to the verification request containing the context information of the second terminal. On the terminal side, the first terminal can complete a simple triggering operation to generate a verification scenario access request containing the context information of the first terminal and the verification scenario configuration information, thereby effectively simplifying the operation process of the user. The second terminal can display the verification result corresponding to the verification target, thereby achieving visual feedback of the execution result of the service link.

[0046] By using the verification method of the service link, on the one hand, the configuration process in the verification process of the service link is effectively simplified by automatically configuring the white list of each to-be-verified node. On the other hand, the node-level control of the link based on the automatically configured white list can ensure that the verification request carrying the already-accessed context information can stably hit the preset target logical branch in the service link, avoid result deviation caused by shunting uncertainty, shorten the problem troubleshooting period in the verification process of the service link, and improve the verification efficiency of the service link. BRIEF DESCRIPTION OF DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required to be used in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0048] Figure 1 An application scenario schematic diagram of a verification method of a service link provided by an exemplary embodiment of the present application;

[0049] Figure 2 An application environment schematic diagram of a verification method of a service link provided by an exemplary embodiment of the present application;

[0050] Figure 3 A flowchart of a service link verification method provided for an exemplary embodiment of the present application is shown in the figure;

[0051] Figure 4 A schematic diagram of a verification scene configuration page provided for an exemplary embodiment of the present application is shown in the figure;

[0052] Figure 5 A flowchart of another service link verification method provided for an exemplary embodiment of the present application is shown in the figure;

[0053] Figure 6 A structural schematic diagram of a service link verification device provided for an exemplary embodiment of the present application is shown in the figure;

[0054] Figure 7 A structural schematic diagram of another service link verification device provided for an exemplary embodiment of the present application is shown in the figure;

[0055] Figure 8 A structural schematic diagram of an electronic device provided for an exemplary embodiment of the present application is shown in the figure;

[0056] Figure 9 A structural schematic diagram of another electronic device provided for an exemplary embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical scheme and advantages of the present application clearer, the present application is further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application.

[0058] In the description of the present application, it should be understood that the terms "first", "second" and the like are only for the purpose of description and should not be understood as indicating or implying relative importance. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances. In addition, in the description of the present application, "multiple" means two or more, unless otherwise specified. "And / or", which describes the relationship between the associated objects, means that there can be three relationships, for example, A and / or B can mean that there are three cases of A alone, A and B together, and B alone. The character " / " generally represents an "or" relationship between the associated objects before and after it.

[0059] In order to more clearly describe the technical scheme of the embodiments of the present application, before the description, some concepts in the present application are described in detail to better understand the present scheme.

[0060] Service link: In the present scheme, it refers to the complete request processing path from the terminal side to the server side.

[0061] To-be-verified node: a functional module to be verified in a service link. The to-be-verified node can be an experimental node for performing a function experiment, a delivery node for delivering content, an engine node for recalling relevant content, etc.

[0062] Verification scenario: a service link execution rule set for a verification target (such as a service function or a service rule). The verification scenario ensures that a verification request hits a target logical branch by controlling the execution strategy of each to-be-verified node in the service link.

[0063] The following describes an application scenario to which the embodiments of the present application are applicable. Figure 1 The following describes an application scenario to which the embodiments of the present application are applicable.

[0064] A certain food delivery APP needs to newly launch a service function A. In order to ensure that the service function A after being launched meets the expectations, the execution effect of the associated service link needs to be verified before being released.

[0065] Please refer to Figure 1 The verification process of the service link can be divided into a verification scenario configuration stage, a verification configuration identifier generation stage, a verification scenario access stage, and a verification execution stage. The specific implementation process of each stage is as follows.

[0066] In the verification scenario configuration stage, a user (such as an acceptance person) sets the verification strategy configuration information of each to-be-verified node in the service link in the background service system of the food delivery APP, including setting the environment configuration information of the environment node, the page configuration information of the page node, the experiment configuration information of the experimental node, the crowd configuration information of the crowd node, the recall configuration information of the engine node, and the delivery configuration information of the delivery node in the service link.

[0067] In the verification configuration identifier generation stage, the background service system of the food delivery APP generates a two-dimensional code corresponding to the verification scenario through a two-dimensional code generator according to all the configuration information set above.

[0068] In the verification scenario access stage, the user scans the two-dimensional code above through a terminal (such as a mobile phone) that has logged in the food delivery APP, and enters the terminal information collection page. After the user authorizes to upload the user identifier in the food delivery APP, the device identifier of the terminal, and other terminal context information to the background service system in 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 background service system. The background service system calls different service interfaces through a verification scenario access center according to the verification scenario configuration information in the verification scenario access request, and adds the user identifier and the device identifier in the terminal context information to the white list of each to-be-verified node as needed, so as to ensure that the subsequent verification request of the terminal can hit the verification scenario above.

[0069] In the verification execution phase, the user triggers the service function A through the takeout APP on the terminal (for example, clicks the service function A entry), and the terminal generates a verification request including the terminal context information in response to the verification operation triggered by the user for the service function A, and sends the verification request to the background service system. The background service system obtains the execution result of the service link according to the terminal context information in the verification request, the white list of each to-be-verified node, and the verification strategy configuration information of each to-be-verified node, and sends the execution result to the terminal. The terminal displays the service function A based on the execution result for the user to compare with the expectation.

[0070] The verification method of the service link provided by the embodiments of the present application can be applied in an application environment as shown in the figure. Figure 2 The first terminal 10 and the second terminal 20 communicate with the server 30 through a 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 a background server corresponding to the online APP. The data storage system can store data required to be processed by the server 30, for example, store verification strategy configuration records, etc. The data storage system can be integrated on the server 30, or placed on a cloud or other network server.

[0071] In some possible embodiments, the server 30 obtains the verification scene configuration information of the service link in response to the verification scene configuration operation of the user, generates a verification configuration identifier corresponding to the verification scene according to the verification scene configuration information of the service link, and sends the verification configuration identifier to the first terminal 10. The verification scene configuration information of the service link includes the verification strategy configuration information of each to-be-verified node in the service link. The first terminal 10 receives the verification configuration identifier sent by the server 30, generates a verification scene access request in response to the triggering operation of the user for the verification configuration identifier, and sends the verification scene access request to the server 30. The verification scene access request includes the verification scene configuration information of the service link and the first terminal context information of the first terminal 10. The server 30 receives the verification scene access request sent by the first terminal 10 based on the verification configuration identifier, adds the first terminal context information to the white list of each to-be-verified node in response to the verification scene access request according to the verification strategy configuration information of each to-be-verified node. The second terminal 20 generates a verification request in response to the verification operation triggered by the user for the verification target, and sends the verification request to the server 30. The verification request includes the second terminal context information of the second terminal 20. The server 30 obtains the execution result of the service link in response to the verification request according to the verification strategy configuration information of each to-be-verified node, the white list of each to-be-verified node, and the second terminal context information. The execution result is sent to the second terminal 20. The second terminal 20 displays the verification result corresponding to the verification target based on the execution result.

[0072] It can be understood that the online APPs described above 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 smart phones, tablet computers, personal computers, notebook computers, Internet of Things devices, and portable wearable devices, etc. The Internet of Things device can be a smart speaker, a smart TV, a smart air conditioner, a smart vehicle-mounted device, etc. The portable wearable device can be a smart watch, a smart bracelet, a head-mounted device, etc. The first terminal 10 and the second terminal 20 can each be implemented by a single terminal device or a terminal cluster composed of multiple terminals. The server 30 can be implemented by an independent server or a server cluster composed of multiple servers.

[0073] In one embodiment, as shown in Figure 3 a service link verification method is provided. The method is applied to an application environment as shown in Figure 2 for example, and includes the following steps:

[0074] S301: The server 30 acquires service link verification scene configuration information in response to a user's verification scene configuration operation.

[0075] The service link verification scene configuration information is set based on a verification target. The service link verification scene configuration information includes verification strategy configuration information of each verification node in the service link. The verification strategy configuration information of each verification node in the service link includes at least one of the following: environment configuration information of an environment node in the service link, page configuration information of a page node in the service link, experiment configuration information of an experiment node in the service link, crowd configuration information of a crowd node in the service link, recall configuration information of an engine node in the service link, and delivery configuration information of a delivery node in the service link.

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

[0077] For example, please see Figure 4 Users can base on Figure 4 The verification scenario configuration page, as shown, allows users to input verification scenario configuration operations, including entering the verification scenario name, selecting nodes to be verified, and entering verification strategy configuration information for each node. Specifically, after entering the verification scenario name, the user can select environment nodes, page nodes, experiment nodes, audience nodes, engine nodes, and delivery nodes as nodes to be verified. For environment nodes, the user can configure the environment release order ID; for page nodes, the user can configure the page route version number; for experiment nodes, the user can configure the experiment ID and experiment bucket ID; for audience nodes, the user can configure the audience package ID; for engine nodes, the user can configure the recall strategy ID; and for delivery nodes, the user can configure the delivery plan ID. In response to the user's verification scenario configuration operations input on the verification scenario configuration page, server 30 obtains the following content as the verification scenario configuration information for the service link: the verification scenario name of the service link, the environment release order ID corresponding to the environment node in the service link, the page route version number corresponding to the page node in the service link, the experiment ID and experiment bucket ID of the experiment node in the service link, the audience package ID corresponding to the audience 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.

[0078] In this embodiment, the server 30 responds to the user's verification scenario configuration operation to centrally acquire the verification policy configuration information corresponding to each of the environment node, the page node, the experiment node, the crowd node, the engine node and the delivery node, and form the verification scenario configuration information of the entire service link. In this way, on the one hand, it is helpful to generate a unified verification configuration identifier of the service link based on the verification scenario configuration information in the subsequent stage, and realizes the automatic reporting of the terminal context information; on the other hand, it is helpful to automatically add the 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 in the subsequent stage, without manually configuring each node, and the entire process effectively improves the verification efficiency of the service link.

[0079] 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.

[0080] The verification configuration identifier is a unique identifier generated according to the verification scenario configuration information of the service link, and the terminal can acquire the verification scenario configuration information of the service link based on the unique identifier and send a verification scenario access request containing the verification scenario configuration information and the terminal context information to the server. It can be understood that the verification configuration identifier can be a uniform resource locator (URL), a two-dimensional code (i.e. a graphical encoding of the URL), etc.

[0081] Optionally, the server 30 generates a two-dimensional code corresponding to the verification scenario according to the verification scenario configuration information of the service link through a two-dimensional code generator. It is worth noting that the two-dimensional code contains a URL pointing to a terminal information collection page, and the URL embeds the verification scenario configuration information of the service link.

[0082] In this embodiment, the server 30 generates a verification configuration identifier corresponding to the verification scenario according to 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.

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

[0084] Optionally, the server 30 sends the generated two-dimensional code to the first terminal 10 through a network interface.

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

[0086] Optionally, the first terminal 10 receives the two-dimensional code sent by the server 30 through a network interface.

[0087] S305: The first terminal 10 generates a verification scenario access request in response to a trigger operation of the user for the verification configuration identifier.

[0088] The first terminal 10 is a terminal that triggers a verification scenario access request based on a verification configuration identifier (such as a two-dimensional code) in the verification scenario access stage. The verification scenario access request is a request triggered by the terminal based on the verification configuration identifier (such as a two-dimensional code), which is used to trigger the server to add the terminal context information to the whitelist of each node to be verified, so as 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 verification scenario configuration information of the service link and 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 first user identifier can be a personal account identifier logged in the online APP of the first terminal 10. The first terminal identifier can be a device number of the first terminal 10, a system type identifier (such as iOS, Android, etc.) of the first terminal 10, a version number corresponding to the system type of the first terminal 10, etc.

[0089] Optionally, the user scans the two-dimensional code through the first terminal 10, and the first terminal 10 generates a verification scenario access request in response to the scanning operation of the user for the two-dimensional code. Specifically, in the process of generating the verification scenario access request by the first terminal 10, the first terminal 10 parses the URL embedded in the two-dimensional code and jumps to the terminal information collection page; after the user authorizes to upload the terminal context information such as the user identifier in the takeout APP and the device identifier of the terminal to the server on the terminal information collection page, the first terminal 10 generates a verification scenario access request containing the first terminal context information and the verification scenario configuration information in response to the information collection authorization operation of the user.

[0090] 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 of the user for the verification configuration identifier (such as a two-dimensional code), which helps the server to automatically add the terminal context information to the whitelist of each node to be verified based on the verification scenario access request, not only reduces the operation threshold of the user, but also simplifies the operation process of the user, thereby effectively improving the verification efficiency of the service link.

[0091] S306: The first terminal 10 sends the verification scenario access request to the server 30.

[0092] Optionally, the first terminal 10 sends the verification scenario access request to the server 30 through a network interface.

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

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

[0095] S308: In response to the verification scenario access request, the server 30 adds the first terminal context information to the white list of each to-be-verified node according to the verification policy configuration information of each to-be-verified node.

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

[0097] Specifically, in the case where 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, adds the first terminal identifier to the white list of the environment node, to realize the logical association between the first terminal identifier and the environment publishing single identifier, and ensure that the subsequent verification request of the first terminal 10 can hit the specified client running environment.

[0098] In the case where 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, adds the first terminal identifier to the white list of the page node, to realize the logical association between the first terminal identifier and the page version identifier, and ensure that the subsequent verification request of the first terminal 10 can hit the specified routing page version.

[0099] In the case where the verification scenario configuration information includes the experiment configuration information of the experiment node, the server 30 calls the service interface of the experiment node according to the experiment configuration information of the experiment node, adds the first user identifier to the white list of the experiment node, to realize the logical association between the first user identifier and the experiment identifier and the experiment bucket identifier, and ensure that the subsequent verification request of the first terminal 10 can hit the specified experiment group.

[0100] In the case where 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, adds the first user identifier to the white list of the crowd node, to realize the logical association between the first user identifier and the crowd package identifier, and ensure that the subsequent verification request of the first terminal 10 can hit the specified crowd characteristics.

[0101] In a case where the verification scenario configuration information comprises the recall configuration information of the engine node, the server 30 adds the first user identifier to the white list of the engine node according to the recall configuration information of the engine node, so as to realize the logical association between the first user identifier and the recall policy identifier, and ensure that the subsequent verification request of the first terminal 10 can hit the specified recall policy.

[0102] In a case where the verification scenario configuration information comprises the delivery configuration information of the delivery node, the server 30 adds the first user identifier to the white list of the delivery node according to the delivery configuration information of the delivery node, so as to realize the logical association between the first user identifier and the delivery plan identifier, and ensure that the subsequent verification request of the first terminal 10 can hit the specified delivery plan.

[0103] In the embodiment, the server 30 adds the terminal context information to the white list of the corresponding node according to the verification policy configuration information of each to-be-verified node in response to the verification scenario access request, realizes the automatic configuration of the white list of the service link multi-node, effectively simplifies the configuration process in the verification process of the service link, and improves the verification efficiency of the service link.

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

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

[0106] Optionally, the user triggers the service function A (for example, clicks the service function A portal) through the online APP on the second terminal 20, and the second terminal 20 generates a verification request comprising second terminal context information in response to the verification operation triggered by the user for the service function A.

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

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

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

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

[0111] S312: The server 30 acquires the execution result of the service link according to the verification policy configuration information of each to-be-verified node, the white list of each to-be-verified node, and the second terminal context information in response to the verification request.

[0112] Optionally, the server 30 judges whether the second terminal context information hits the white list of any to-be-verified node in the to-be-verified nodes in response to the verification request. If yes, the execution result of the any to-be-verified node is acquired according to the verification policy configuration information of the any to-be-verified node; if not, the execution result of the any to-be-verified node is acquired according to the dynamic shunting rule. Finally, the server 30 acquires the execution result of the service link according to the execution result of each to-be-verified node in the service link.

[0113] In this embodiment, the server 30 ensures that the verification request carrying the admitted context information (the first terminal context information in this embodiment) can stably hit the preset target policy in the service link through the node-level control based on the white list mechanism, avoids the result deviation caused by the shunting uncertainty, shortens the problem troubleshooting period in the service link verification process, and thus improves the verification efficiency of the service link.

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

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

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

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

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

[0119] Optionally, the execution result of the service link includes specific service data and link state identifier of the service link. The specific service data can be template identifier of a page rendering template, filling data of the page rendering template, recommended content set, etc. The link state identifier of the service link can include the verification policy identifier (such as experiment identifier, experiment bucket identifier) currently executed by each to-be-verified node in the service link, etc.

[0120] Exemplarily, assuming that the verification target is an activity rule, after the server 30 sends the template identifier of the page rendering template, the filling data of the page rendering template, the recommended content set, the experiment identifier and the experiment bucket identifier of the current execution of the service link to the second terminal 20, the second terminal 20 can render the corresponding activity page in the online APP running thereon based on the execution result; meanwhile, the second terminal 20 can generate debugging information according to the verification policy identifier of the current execution of each to-be-verified node and the verification policy identifier pre-configured by the user at each to-be-verified node, and display the debugging information in the form of a floating layer or a log, for the user to confirm whether the activity rule takes effect as expected.

[0121] 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 containing the service data and the link state identifier, thereby realizing the visual feedback of the execution result of the service link and providing the user with necessary link verification basis. In the above manner, on the one hand, the user can confirm whether the verification target takes effect by intuitively viewing the page content, thereby improving the perceptibility and credibility of the verification process; on the other hand, the terminal can automatically analyze the link state identifier and determine the policy hit of each key node, thereby improving the automation of the verification process, and the entire process effectively improves the verification efficiency of the service link.

[0122] In the above verification method of the service link, on the server side: by obtaining the verification scene configuration information of the service link, aggregating the verification policy configuration information of each to-be-verified node in the service link, generating the verification configuration identifier corresponding to the verification scene, and adding the context information to the whitelist of each to-be-verified node according to the verification scene access request sent by the first terminal based on the identifier, the automatic configuration of the whitelist of each node can be realized; by responding to the verification request sent by the second terminal, obtaining the execution result of the service link according to the verification policy configuration information of each to-be-verified node, the whitelist of each to-be-verified node and the context information of the second terminal, the link can be controlled at the node level based on the automatically configured whitelist. On the terminal side: by the first terminal, a simple triggering operation is completed to generate the verification scene access request containing the context information of the first terminal and the verification scene configuration information, thereby effectively simplifying the operation process of the user; by the second terminal, the verification request containing the context information of the second terminal is sent to the server to display the verification result corresponding to the verification target, thereby realizing the visual feedback of the execution result of the service link.

[0123] By using the service link verification method, on the one hand, the configuration process in the service link verification process is effectively simplified by automatically configuring the white list of each to-be-verified node; on the other hand, the white list configured automatically is used to control the link at the node level, so that the verification request carrying the admitted context information can stably hit the preset target logical branch in the service link, the result deviation caused by uncertain shunting is avoided, the problem troubleshooting period in the service link verification process is shortened, and the verification efficiency of the entire service link is effectively improved.

[0124] In one embodiment, as shown in Figure 5 Another service link verification method is provided, which is applied to Figure 2 The server 30 shown in the figure is taken as an example for illustration, which includes the following steps:

[0125] S501: In response to a verification scenario configuration operation of a user, verification scenario configuration information of a service link is acquired.

[0126] 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 strategy configuration information of each to-be-verified node in the service link. The verification strategy configuration information of each to-be-verified node in the service link includes environment configuration information of an environment node in the service link, page configuration information of a page node in the service link, experiment configuration information of an experiment node in the service link, crowd configuration information of a crowd node in the service link, recall configuration information of an engine node in the service link, and delivery configuration information of a delivery node in the service link.

[0127] Specifically, please refer to S301 described above, which will not be repeated here.

[0128] S502: The verification strategy configuration information of each to-be-verified node in the service link is respectively associated with the identification of the verification scenario and stored in a database to form each verification strategy configuration record.

[0129] Optionally, after the server 30 acquires the verification scenario configuration information of the service link, each piece of verification strategy configuration information is saved in the database to form each verification strategy configuration record.

[0130] Exemplarily, the server 30 stores the environment configuration information (such as the environment release ID, etc.) of the environment node, the page configuration information (such as the page routing version number, etc.) of the page node, the experiment configuration information (such as the experiment ID, the experiment bucket ID, etc.) of the experiment node, the crowd configuration information (such as the crowd package ID, etc.) of the crowd node, the recall configuration information (such as the recall strategy ID, etc.) of the engine node, and the delivery configuration information (such as the delivery plan ID, etc.) of the delivery node in association with the name of the verification scene to the database respectively, to form six verification strategy configuration records, facilitating subsequent tracing and reuse.

[0131] In this embodiment, the server 30 stores each piece of verification strategy configuration information in the verification scene configuration information in association with the verification scene configuration identifier to the database, which not only facilitates subsequent tracing of the specific configuration parameters corresponding to the verification scene based on the verification scene configuration identifier, but also facilitates subsequent flexible reuse of these verification strategy configuration records to regenerate the verification configuration identifier, thereby improving the traceability and efficiency of the service link verification.

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

[0133] Specifically, please refer to S302 described above, which will not be repeated here.

[0134] S504: Receive a verification scene access request sent by the first terminal based on the verification configuration identifier.

[0135] The verification scene access request includes the verification scene configuration information of the service link and the first terminal context information of the first terminal.

[0136] S505: In response to the verification scene access request, add the first terminal identifier to the white list of the environment node according to the environment configuration information of the environment node.

[0137] Optionally, the server 30 adds the first terminal identifier to the white list of the environment node according to the environment configuration information of the environment node in response to the verification scene access request, calls the white list configuration service interface of the environment node, and realizes the logical association between the first terminal identifier and the environment release identifier, to ensure that the subsequent verification request of the first terminal 10 can hit the specified client running environment.

[0138] S506: Add the first terminal identifier to the white list of the page node according to the page configuration information of the page node.

[0139] Optionally, the server 30 adds the first terminal identifier to the whitelist of the page node according to the page configuration information of the page node, and calls a whitelist configuration service interface of the page node, so as to realize logical association between the first terminal identifier and the page version identifier, and ensure that a subsequent verification request of the first terminal 10 can hit a specified routing page version.

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

[0141] Optionally, the server 30 adds the first user identifier to the whitelist of the experiment node according to the experiment configuration information of the experiment node, and calls a whitelist configuration service interface of the experiment node, so as to realize logical association between the first user identifier and the experiment identifier and the experiment bucket identifier, and ensure that a subsequent verification request of the first terminal 10 can hit a specified experiment group.

[0142] Specifically, the experiment configuration information of the experiment node includes an experiment identifier of a target experiment and an experiment bucket identifier of a target experiment bucket. The server 30 can add the first user identifier to the whitelist of the target experiment bucket according to the experiment identifier and the experiment bucket identifier, and call a whitelist configuration service interface of the experiment node, so that the server 30 executes the experiment strategy of the specified experiment group in the experiment node when processing a verification request containing the first user identifier in the subsequent processing.

[0143] In addition, the server can also add the first user identifier to the whitelist of the target experiment bucket according to the experiment identifier, and call a whitelist configuration service interface of the experiment node, so that the server 30 executes the experiment strategy of each experiment group corresponding to the experiment in the experiment node when processing a verification request containing the first user identifier in the subsequent processing, and returns the currently executed experiment identifier and experiment bucket identifier to the second terminal, so that the second terminal displays the currently executed experiment identifier and experiment bucket identifier in the form of a floating layer or a log while displaying the verification result.

[0144] In this embodiment, the server 30 establishes logical association between the first user identifier and the experiment identifier and the experiment bucket identifier by calling a whitelist configuration service interface of the experiment node, so as to ensure that a subsequent verification request of the first terminal can stably hit a specified experiment group, avoid path uncertainty caused by random shunting of natural traffic, and ensure the accuracy of functional experiment verification. In addition, the server 30 also supports whitelist configuration in the experiment node according to only the experiment identifier, and executes the strategy logic of all experiment groups under the experiment when processing a verification request, so that a single verification can cover multiple branch logics, effectively improving verification coverage and verification efficiency.

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

[0146] Optionally, the server 30 adds the first user identifier to the whitelist of the crowd node according to the crowd configuration information of the crowd node, calls a whitelist configuration service interface of the crowd node, and realizes logical association between the first user identifier and the crowd package identifier, so as to ensure that a subsequent verification request of the first terminal 10 can hit the specified crowd feature.

[0147] S509: According to the recall configuration information of the engine node, the first user identifier is added to the whitelist of the engine node.

[0148] Optionally, the server 30 adds the first user identifier to the whitelist of the engine node according to the recall configuration information of the engine node, calls a whitelist service interface of the engine node, and realizes logical association between the first user identifier and the recall strategy identifier, so as to ensure that a subsequent verification request of the first terminal 10 can hit the specified recall strategy.

[0149] S510: According to the delivery configuration information of the delivery node, the first user identifier is added to the whitelist of the delivery node.

[0150] Optionally, the server 30 adds the first user identifier to the whitelist of the delivery node according to the delivery configuration information of the delivery node, calls a whitelist service interface of the delivery node, and realizes logical association between the first user identifier and the delivery plan identifier, so as to ensure that a subsequent verification request of the first terminal 10 can hit the specified delivery plan.

[0151] S511: Receive the verification request sent by the second terminal for the verification target.

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

[0153] S512: In response to the verification request, according to the verification strategy configuration information of each to-be-verified node, the whitelist of each to-be-verified node and the second terminal context information, the execution result of the service link is obtained.

[0154] Optionally, the server 30 responds to the verification request, and for any to-be-verified node in the to-be-verified nodes, according to the verification strategy configuration information of any to-be-verified node, judges whether the second terminal context information hits the whitelist of any to-be-verified node.

[0155] Exemplarily, for the experimental node in the service link, the server 30 judges whether the second user identifier in the second terminal context information is consistent with the first user identifier in the experimental node whitelist according to the verification policy configuration information of the experimental node. If consistent, the server 30 acquires the execution result of the experimental node according to the verification policy configuration information of any to-be-verified node; if inconsistent, the server 30 acquires the execution result of the experimental node according to the dynamic shunting rule. Finally, the server 30 acquires the execution result of the entire link according to the execution result of each to-be-verified node in the service link.

[0156] In the embodiment, the server 30 judges whether the second context information in the verification request is consistent with the information in the whitelist of each to-be-verified node through node-level control based on the whitelist mechanism, so as to ensure that the verification request carrying the admitted context information can stably hit the preset target policy in the service link, avoid the result deviation caused by shunting uncertainty, and further shorten the problem troubleshooting period in the service link verification process and improve the verification efficiency of the service link.

[0157] S513: In response to the reuse request for at least one verification policy configuration record in the database, a corresponding verification scene configuration identifier corresponding to a corresponding verification scene of the at least one verification policy configuration record is generated.

[0158] Optionally, after the service link is verified for a certain verification scene, the user can also send a reuse request for at least one verification policy configuration record in the database to the server 30 when setting new verification scene configuration information. After receiving the reuse request, the server 30 can generate a corresponding verification scene configuration identifier corresponding to a new verification scene based on the reused at least one verification policy configuration record and the verification policy configuration information newly set by the user.

[0159] In the embodiment, the server 30 generates a new verification scene configuration identifier based on the existing record in response to the reuse request for the existing verification policy configuration record in the database, realizes flexible reuse of verification configuration and efficient generation of verification configuration identifier, avoids the user from repeatedly manually inputting the same or similar verification policy during the configuration process, reduces the configuration workload of the user, and improves the verification efficiency of the service link.

[0160] In the service link verification method, on one hand, the white list of each to-be-verified node is automatically configured by calling the white list configuration interface of each to-be-verified node according to the verification policy configuration information of each to-be-verified node, thereby effectively simplifying the configuration process in the service link verification process; on the other hand, each piece of verification policy configuration information in the verification scene configuration information is stored in association with the verification scene configuration identifier in the database, thereby facilitating subsequent backtracking and reuse of the existing verification policy configuration record; and on the other hand, in response to a reuse request for the existing verification policy configuration record in the database, a new verification scene configuration identifier is generated based on the existing record, thereby realizing flexible reuse of the verification configuration and efficient generation of the verification configuration identifier, avoiding repeated manual input of the same or similar verification policy by the user in the configuration process, and effectively improving the accuracy, flexibility, traceability and efficiency of the service link verification.

[0161] It should be understood that, although each step in the flowchart involved in each embodiment as described above is displayed in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other sequences. Moreover, at least part of the steps in the flowchart involved in each embodiment as described above can include multiple steps or stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of these steps or stages is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or steps or stages in other steps.

[0162] Based on the inventive concept of the above service link verification method, as shown in Figure 8 The embodiments of the present application also provide a service link verification device 600 for implementing the above service link verification method applied to a server. The service link verification device 600 comprises:

[0163] The acquisition module 601 is configured to acquire service link verification scene configuration information. The service link verification scene configuration information is based on a verification target. The service link verification scene configuration information comprises verification policy configuration information of each to-be-verified node in the service link.

[0164] The generation module 602 is configured to generate a verification configuration identifier corresponding to a verification scene according to the service link verification scene configuration information.

[0165] The first receiving module 603 is configured to receive a verification scene access request sent by a first terminal based on the verification configuration identifier. The verification scene access request comprises the service link verification scene configuration information and first terminal context information of the first terminal.

[0166] The first response module 604 is configured to, in response to the verification scene access request, add the first terminal context information to the whitelist of each to-be-verified node according to the verification policy configuration information of the to-be-verified node.

[0167] The second receiving module 605 is configured to receive a verification request sent by the second terminal for the verification target; the verification request comprises second terminal context information of the second terminal.

[0168] The second response module 606 is configured to, in response to the verification request, acquire an execution result of the service link according to the verification policy configuration information of each to-be-verified node, the whitelist of each to-be-verified node, and the second terminal context information.

[0169] The first sending module 607 is configured to send 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.

[0170] In an embodiment, the verification policy configuration information of each to-be-verified node in the service link comprises at least one of the following: environment configuration information of an environment node in the service link, page configuration information of a page node in the service link, experiment configuration information of an experiment node in the service link, crowd configuration information of a crowd node in the service link, recall configuration information of an engine node in the service link, and delivery configuration information of a delivery node in the service link.

[0171] In an embodiment, the first terminal context information comprises a first user identifier and a first terminal identifier; and the first response module 604 is specifically configured 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 experiment node according to the experiment configuration information of the experiment 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.

[0172] In an embodiment, the experiment configuration information of the experiment node comprises an experiment identifier of a target experiment and an experiment bucket identifier of a target experiment bucket; and the first response module 604 is specifically configured to: according to the experiment identifier and the experiment bucket identifier, call a whitelist configuration service interface of the experiment node, and add the first user identifier to the whitelist of the target experiment bucket.

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

[0174] In one embodiment, the service link verification device 600 further includes a data storage module, which is used to associate the verification strategy configuration information of each node to be verified in the service link with the identifier of the verification scenario and store it in the database to form each verification scenario configuration record.

[0175] In one embodiment, the service link verification device 600 further includes a data reuse module, which is used to generate a corresponding verification scenario configuration identifier based on the at least one verification scenario configuration record in response to a reuse request for at least one verification scenario configuration record in the database.

[0176] The inventive concept based on the above-mentioned service link verification method, such as Figure 7 As shown, this application embodiment also provides a service link verification apparatus 700 for implementing the above-described service link verification method applied to a first terminal. The service link verification apparatus 700 includes:

[0177] 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 strategy configuration information of each node to be verified in the service link.

[0178] The third response module 702 is used to generate a verification scenario access request in response to the user's trigger operation on the verification configuration identifier; 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;

[0179] The second sending module 703 is configured to send the verification scene access request to a server, so that the server receives the verification scene access request, adds the first terminal context information to a whitelist of each to-be-verified node according to the verification policy configuration information of each to-be-verified node in response to the verification scene access request, receives a verification request sent by the second terminal to the verification target, the verification request comprising second terminal context information of the second terminal, obtains an execution result of a service link according to the verification policy configuration information of each to-be-verified node, the whitelist of each to-be-verified node and the second terminal context information in response to the verification request, and sends 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.

[0180] In one embodiment, the verification configuration is a two-dimensional code, and the third response module 702 is specifically configured to generate the verification scene access request in response to a scanning operation of the two-dimensional code by the user.

[0181] The modules in the service link verification apparatus 600 and the service link verification apparatus 700 described above can be all or partially implemented by software, hardware or a combination thereof. The modules described above can be embedded in or independent of a processor in a computer device in a hardware form, or stored in a memory in a computer device in a software form, so as to be called and executed by a processor to perform the operations corresponding to the modules.

[0182] Embodiments of the present application also provide an electronic device, which can be a server, and an internal structure diagram thereof can be as shown in Figure 8 Please refer to Figure 8 The electronic device comprises 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 through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the electronic device is configured to provide computing and control capabilities. The memory of the electronic device comprises 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 operating system and the computer program in the non-volatile storage medium to run. The database of the electronic device is configured to store verification scene configuration records and the like. The input / output interface of the electronic device is configured to exchange information between the processor and external devices. The communication interface of the electronic device is configured to communicate with external terminals through network connection. The processor of the electronic device executes the computer program to implement a service link verification method.

[0183] It is worth noting that the electronic device can also be a terminal, and an internal structure diagram thereof can be as shown in Figure 9 Please refer to Figure 9The electronic device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the electronic device is configured 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 and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The input / output interface of the electronic device is configured to exchange information between the processor and external devices. The communication interface of the electronic device is configured to perform wired or wireless communication with external terminals, and the wireless communication can be achieved through WIFI, mobile cellular network, NFC (Near Field Communication) or other technologies. The computer program is executed by the processor to implement a service link verification method. The display unit of the electronic device is configured to form a visually visible picture, which 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. The input device of the electronic device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad arranged on the shell of the electronic device, or an external keyboard, touchpad or mouse, etc.

[0184] The embodiments of the present application also provide a computer storage medium, which stores instructions, and when the instructions are run on a computer or a processor, the computer or the processor executes one or more steps of the above-mentioned embodiments. When the components of the above-mentioned electronic device are realized in the form of software function units and sold or used as independent products, they can be stored in the above-mentioned computer readable storage medium.

[0185] In the above embodiments, all or part of the methods can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the methods can 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 can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer storage medium or transmitted by the computer storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through a wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that includes one or more available media sets. The available media can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital versatile disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0186] Those of ordinary skill in the art understand that all or part of the processes in the above embodiments can be implemented by a computer program to instruct the relevant hardware, which can be stored in a computer readable storage medium. The program can include the processes of the above embodiments when executed. The storage medium includes ROM, RAM, magnetic or optical disks, and various program code storage media. In the case of no conflict, the technical features in the embodiments and the implementation schemes can be combined arbitrarily.

[0187] The above embodiments are only preferred embodiment modes of the present application, and do not limit the scope of the present application. Without departing from the design spirit of the present application, various modifications and improvements of the technical solutions of the present application made by those of ordinary skill in the art should fall within the protection scope determined by the claims.

[0188] It should be noted that the technical solutions of the present application can be applied to transactions, distribution services of instant e-commerce platforms, such as Taobao flash shopping, Taofxian, Eleme 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 related data need to comply with relevant laws, regulations and standards of relevant countries and regions. For example, the "first terminal context information", "second terminal context information", "first user identifier", "first terminal identifier", "second user identifier", "second terminal identifier" and the like involved in the present specification are all obtained under the condition of full authorization.

[0189] The foregoing described specific embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown or sequential order in order to achieve the desired results. In some implementations, multitasking and parallel processing can be advantageous.

Claims

1. A method for verifying a service link, characterized in that, Applied to a server, the method includes: Obtain 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 strategy configuration information of each node to be verified in the service link; Based on the verification scenario configuration information of the service link, a verification configuration identifier corresponding to the verification scenario is generated; Receive a verification scenario access request sent by a first terminal based on the verification configuration identifier; 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; In response to the verification scenario access request, the first terminal context information is added to the whitelist of each node to be verified according to the verification policy configuration information of each node to be verified. Receive 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, the execution result of the service link is obtained 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; 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; 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, audience configuration information of the audience 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.

2. The method as described in claim 1, characterized in that, The first terminal context information includes a first user identifier and a first terminal identifier; The step of 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: Based on the environment configuration information of the environment node, the first terminal identifier is added to the whitelist of the environment node; and / or Based on the page configuration information of the page node, the first terminal identifier is added to the whitelist of the page node; and / or Based on the experimental configuration information of the experimental node, the first user identifier is added to the whitelist of the experimental node; and / or Based on the crowd configuration information of the crowd node, the first user identifier is added to the whitelist of the crowd node; and / or Based on the recall configuration information of the engine node, the first user identifier is added to the whitelist of the engine node; and / or Based on the deployment configuration information of the deployment node, the first user identifier is added to the whitelist of the deployment node.

3. The method as described in claim 2, characterized in that, 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 step of adding the first user identifier to the whitelist of the experimental node based on the experimental configuration information of the experimental node includes: Based on the experiment identifier and the experiment bucket identifier, the whitelist configuration service interface of the experiment node is invoked to add the first user identifier to the whitelist of the target experiment bucket.

4. The method as described in claim 1, characterized in that, The step of obtaining 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 includes: For any of the nodes to be verified, determine whether the second terminal context information matches the whitelist of any of the nodes to be verified. If so, the execution result of any node to be verified is obtained according to the verification strategy configuration information of any node to be verified. The execution result of the service link is obtained based on the execution result of any of the nodes to be verified.

5. The method as described in claim 1, characterized in that, After obtaining the verification scenario configuration information of the service link, the method further includes: The verification strategy 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 strategy configuration record.

6. The method as described in claim 5, characterized in that, The method further includes: In response to a reuse request for at least one verification policy configuration record in the database, a corresponding verification scenario configuration identifier is generated based on the at least one verification policy configuration record.

7. A method for verifying a service link, characterized in that, Applied to a first terminal, the method includes: The server receives a verification configuration identifier corresponding to the verification scenario; 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 the verification strategy configuration information of each node to be verified in the service link. In response to a user's trigger operation on the verification configuration identifier, a verification scenario access request is generated; 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; The verification scenario admission request is sent to the server, so that the server: receives the verification scenario admission request; in response to the verification scenario admission 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. 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, audience configuration information of the audience 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.

8. The method as described in claim 7, characterized in that, The verification configuration identifier is a QR code; The step of generating a verification scenario access request in response to a user's trigger operation on a verification configuration identifier includes: In response to the user's scanning operation of the QR code, a verification scenario access request is generated.

9. 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 the 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 the verification strategy 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, and in response to a user's trigger operation on the verification configuration identifier, generate a verification scenario access request and send the verification scenario access request to the server; 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; The server is further configured to receive a verification scenario access request sent by the first terminal based on the verification configuration identifier; and in response to the verification scenario access request, add 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. The second terminal is configured to generate a verification request in response to a verification operation triggered by a user for the verification target, and send the verification request to the server; the verification request includes the second terminal context information of the second terminal; The server is also configured to respond to the verification request by obtaining 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 context information of the second terminal, and sending the execution result to the second terminal. The second terminal is further configured to display the verification result corresponding to the verification target based on the execution result; 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, audience configuration information of the audience 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.

10. A service link verification device, characterized in that, Applied to a server, the device includes: The acquisition module is used to acquire 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 strategy configuration information of each node to be verified in the service link; The generation module is used to generate a verification configuration identifier corresponding to the verification scenario based on the verification scenario configuration information of the service link; The first receiving module is configured to receive a verification scenario access request sent by the first terminal based on the verification configuration identifier; 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; The first response module is used to respond to the verification scenario access request and add the first terminal context information to the whitelist of each node to be verified according to the verification strategy configuration information of each node to be verified. The second receiving module is configured to receive 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. The second response module is used to respond to the verification request and obtain 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. The first sending module is used 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; 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, audience configuration information of the audience 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.

11. A service link verification device, characterized in that, Applied to a first terminal, the device 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 strategy configuration information of each node to be verified in the service link; The third response module is used to generate a verification scenario access request in response to a user's trigger operation on the verification configuration identifier; 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; The second sending module is configured to send the verification scenario admission request to the server, so that the server: receives the verification scenario admission request; in response to the verification scenario admission 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. 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, audience configuration information of the audience 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.

12. An electronic device, characterized in that, include: A processor and a memory; the memory stores a computer program, and the processor executes the computer program to implement the method steps of any one of claims 1-8.

13. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the method steps as claimed in any one of claims 1-8.

Images