Dependency verification method and apparatus, device, storage medium, and product

Abstract

The embodiments of the present disclosure provide a dependency verification method, comprising: acquiring a verification request for a target function, the verification request indicating at least one service related to the target function and at least one interface to be invoked by the at least one service; in response to the verification request, sending an environment deployment request for the at least one service to a simulated operating environment; sending a fault injection request to a fault injection platform to request injection, into the simulated operating environment, of a fault event for a target interface among the at least one interface; in response to receiving an indication of successful fault injection from the fault injection platform, triggering a verification platform to perform first verification on a target function in the simulated operating environment; and on the basis of a first verification result of the first verification received from the verification platform, determining a degree of dependency of the at least one service on the target interface.

Description

Methods, apparatus, devices, storage media, and products for dependency verification Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a method, apparatus, device, storage medium, and product for dependency verification. Background Technology

[0002] In software development, dependency is a crucial concept describing the degree of connection between modules, components, interfaces, or systems, and it plays a significant role in software design, development, testing, and maintenance. Generally, dependencies can be categorized into strong dependencies and weak dependencies. A strong dependency refers to a close and indispensable relationship between modules or components; for example, module A must rely on the correct operation of module B to function. Conversely, if module A can still function normally even when module B is missing or malfunctioning, it is considered a weak dependency. Currently, dependency verification primarily relies on manual methods, a tedious and time-consuming process.

[0003] Summary of the Invention

[0004] In a first aspect of this disclosure, a method for dependency verification is provided. The method includes: in response to receiving a verification request for a target function, sending an environment deployment request to a simulated runtime environment, the verification request indicating at least one service involved in the target function and at least one interface to be invoked by the at least one service, the environment deployment request indicating deployment of the at least one service; sending a fault injection request to a fault injection platform to request the injection of a fault event for a target interface among the at least one interface into the simulated runtime environment; in response to receiving an indication of successful fault injection from the fault injection platform, triggering the verification platform to perform a first verification on the target function in the simulated runtime environment; and determining the degree of dependency of the at least one service on the target interface based on a first verification result received from the verification platform.

[0005] In a second aspect of this disclosure, an apparatus for dependency verification is provided. The apparatus includes: a first sending module configured to, in response to receiving a verification request for a target function, send an environment deployment request to a simulated runtime environment, the verification request indicating at least one service involved in the target function and at least one interface to be invoked by the at least one service, the environment deployment request indicating deployment of the at least one service; a second sending module configured to send a fault injection request to a fault injection platform to request the injection of a fault event for a target interface among the at least one interfaces into the simulated runtime environment; a verification triggering module configured to, in response to receiving an indication of successful fault injection from the fault injection platform, trigger the verification platform to perform a first verification on the target function in the simulated runtime environment; and a dependency degree determination module configured to, based on a first verification result received from the verification platform, determine the dependency degree of the at least one service on the target interface.

[0006] In a third aspect of this disclosure, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the device to perform the method of the first aspect.

[0007] In a fourth aspect of this disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program that can be executed by a processor to implement the method of the first aspect.

[0008] In a fifth aspect of this disclosure, a computer program product is provided. The computer program product includes computer-executable instructions that, when executed by a processor, implement the method according to a first aspect of this disclosure.

[0009] It should be understood that the content described in this content section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0011] Figure 1 shows a schematic diagram of an example environment according to an embodiment of the present disclosure;

[0012] Figure 2 illustrates a schematic diagram of the interaction process for dependency verification according to some embodiments of the present disclosure;

[0013] Figure 3 illustrates a schematic diagram of an example of the association between verification configuration information and multiple requests according to some embodiments of the present disclosure;

[0014] Figure 4 shows a flowchart of an example process for a method for dependency verification according to some embodiments of the present disclosure;

[0015] Figure 5 shows a schematic structural block diagram of an apparatus for dependency verification according to some embodiments of the present disclosure; and

[0016] Figure 6 shows a block diagram of an electronic device in which one or more embodiments of the present disclosure may be implemented. Detailed Implementation

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] It should be noted that the headings of any section / subsection provided herein are not limiting. Various embodiments are described throughout this document, and embodiments of any type may be included under any section / subsection. Furthermore, embodiments described in any section / subsection may be combined in any way with any other embodiments described in the same section / subsection and / or different sections / subsections.

[0019] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other definite and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other definite and implicit definitions may also be included below.

[0020] The embodiments of this disclosure may involve user data, data acquisition, and / or use. All of these aspects comply with applicable laws, regulations, and relevant provisions. In the embodiments of this disclosure, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, in implementing the embodiments of this disclosure, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained in accordance with relevant laws and regulations through appropriate means. The specific methods of notification and / or authorization may vary depending on the actual situation and application scenario, and the scope of this disclosure is not limited in this respect.

[0021] In this specification and the embodiments, any processing of personal information will be carried out only under the premise of legality (such as obtaining the consent of the personal information subject, or being necessary for the performance of a contract), and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information other than that necessary for basic functions will not affect the user's use of basic functions.

[0022] In the field of software development, accurately identifying the degree of dependency (or strong and weak dependencies) between modules, components, or systems is crucial for ensuring the stability, maintainability, and scalability of software. However, as briefly described above, current dependency identification mainly relies on manual processes, which present significant challenges in terms of efficiency and accuracy.

[0023] In one approach, to verify dependencies in a service chain, personnel must manually create a simulated runtime environment and design and execute fault injection targeting specific service interfaces. After confirming successful fault injection, they also need to observe and determine the final strong and weak dependencies on a verification platform through interface testing or functional testing. This entire process is cumbersome and time-consuming, severely impacting the iteration speed of software development.

[0024] In view of this, this disclosure provides a scheme for dependency verification. According to this scheme, firstly, in response to receiving a verification request for a target function, an environment deployment request is sent to a simulated runtime environment. The verification request indicates at least one service involved in the target function and at least one interface to be called by the at least one service; the environment deployment request indicates the deployment of the at least one service. Next, a fault injection request is sent to a fault injection platform to request the injection of a fault event for the target interface among the at least one interface into the simulated runtime environment. In response to receiving an indication of successful fault injection from the fault injection platform, the verification platform is triggered to perform a first verification on the target function in the simulated runtime environment. Then, based on the first verification result received from the verification platform, the degree of dependency of the at least one service on the target interface is determined.

[0025] As will be more clearly understood from the following description, the solution disclosed herein significantly improves the efficiency and accuracy of dependency verification during software development and maintenance by automating the scheduling process. Specifically, the solution disclosed herein can automatically send environment deployment requests to the corresponding simulated runtime environment and fault injection requests to the fault injection platform. This means that the solution disclosed herein eliminates the need to manually create simulated runtime environments and design fault injection tasks, thereby greatly simplifying the verification process, reducing manual intervention, and improving verification efficiency and accuracy. Furthermore, after successful fault injection, the solution disclosed herein can automatically trigger the verification platform to perform verification (e.g., first verification) on the target function in the simulated environment where the fault event was injected, and determine the dependency degree of at least one service on the target interface based on the verification results received from the verification platform (e.g., the first verification result). This automated process effectively solves the problems of high cost and high complexity caused by multi-platform separation in dependency verification, significantly reduces the time cost of manual verification, improves verification efficiency, and thus supports higher frequency verification. Based on the verification results, relevant personnel can quickly and accurately grasp the strength of dependencies, thereby providing better support for subsequent development, testing, and maintenance work.

[0026] The following will further describe in detail various example implementations of this scheme with reference to the accompanying drawings.

[0027] Example Environment

[0028] Figure 1 illustrates a schematic diagram of an example environment 100 according to an embodiment of the present disclosure. Referring to Figure 1, the example environment 100 may include an electronic device 110, a simulation environment platform 120, a fault injection platform 130, a verification configuration platform 160, and a verification platform 140.

[0029] According to embodiments of this disclosure, electronic device 110 acts as a scheduling system, enabling scheduling among various platforms required for dependency verification, thereby completing dependency verification between services and interfaces. During dependency verification, electronic device 110 is associated with simulation environment platform 120, fault injection platform 130, and verification platform 140, respectively. In response to a verification request, electronic device 110 sends corresponding requests to simulation environment platform 120, fault injection platform 130, and verification platform 140, respectively, to invoke the corresponding functions of each platform to perform dependency verification of the target function.

[0030] Simulation environment platform 120 is configured to provide a simulated operating environment corresponding to the target function to be verified. Fault injection platform 130 is configured to inject fault events into the simulated operating environment. Verification platform 140 is configured to test and verify whether the target function can operate normally under the injected fault events.

[0031] Upon receiving verification request 160, electronic device 110 sends an environment deployment request to simulation environment platform 120. Simulation environment platform 120 responds to the environment deployment request by providing a simulated operating environment corresponding to the target function to be verified. To verify the performance of the target function under fault conditions, electronic device 110 continues to send a fault injection request to fault injection platform 130. Fault injection platform 130 responds to the fault injection request by injecting fault events into the simulated operating environment, thereby simulating various possible fault scenarios. To verify the state of the target function after fault injection, electronic device 110 triggers verification platform 140 to perform a series of tests on the target function to verify whether the target function can operate normally under the injected fault events. As an example, electronic device 110 can use verification configuration platform 160 to provide the test cases required for verification to verification platform 140. Verification configuration platform 160 triggers verification platform 140 to test the target function by sending test cases to verification platform 140.

[0032] Through this process, the electronic device 110 can effectively coordinate the work of various platforms and automate operations such as simulated environment deployment, fault injection, and post-fault injection testing and verification.

[0033] As an example, a user can interact with electronic device 110 through a terminal device to view the dependency verification results for a target function. In some embodiments, the terminal device can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, the terminal device can also support any type of user-facing interface (such as "wearable" circuitry).

[0034] In some embodiments, electronic device 110 may be a terminal device. Electronic device 110 may be a server-side device, such as a standalone physical server, or a server cluster or distributed system composed of multiple physical servers. It may also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. Electronic device 110 may, for example, include computing systems / servers, such as mainframes, edge computing nodes, computing devices in a cloud environment, etc.

[0035] The electronic device 110 can establish communication connections with various platforms. These connections can be established via wired or wireless means. Communication connections may include, but are not limited to, Bluetooth connections, mobile network connections, Universal Serial Bus connections, and Wi-Fi connections; the embodiments of this disclosure are not limited in this respect. In the embodiments of this disclosure, the electronic device 110 and various platforms can achieve signaling interaction through these communication connections.

[0036] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure.

[0037] Example Interaction

[0038] Figure 2 illustrates a schematic diagram of an interaction process 200 for dependency verification according to some embodiments of the present disclosure. Referring to Figure 2, in response to receiving a verification request 150 for a target function, the electronic device 110 sends an environment deployment request to a simulated operating environment. The verification request 150 indicates at least one service involved in the target function and at least one interface to be invoked by the at least one service, and the environment deployment request indicates the deployment of the at least one service.

[0039] The target function to be verified can be a function of any application, program, website, service platform / system. Taking a live streaming application as an example, the target function can refer to various functions included in the live streaming application. For example, the target function includes, but is not limited to, the function of starting a live stream, the function of watching a live stream, or the function of commenting on a live stream, etc. At least one service involved in the target function can refer to one or more services required to implement the target function. When the target function involves multiple services, these services can form the service call chain of the target function. As an example, the services involved in the target function can refer to microservices deployed on the server or in the cloud. For example, the services involved in the target function include, but are not limited to, the live stream access microservice or the video stream processing microservice, etc.

[0040] In some embodiments, trigger 201 is configured to send (211) verification request 150 to electronic device 110 to trigger electronic device 110 to perform verification for a target function. In some embodiments, verification request 150 is issued at a predetermined period. The predetermined period can be a pre-set fixed value or a dynamic value that varies according to actual conditions. As an example, trigger 201 can issue verification request 150 at a pre-set fixed period. The fixed period can be, for example, one day, one week, one month, etc. In this way, electronic device 110 can periodically verify the dependency of the target function, thereby timely identifying and resolving potential problems. In addition, verification request 150 can also be issued by trigger 201 based on a specific event, which can be determined according to actual needs, and will not be described in detail in the embodiments of this disclosure.

[0041] In response to verification request 150, electronic device 110 sends an environment deployment request (212) to simulation environment platform 120. Simulation environment platform 120 can provide a simulated runtime environment related to the operation of the target function. This simulated runtime environment is isolated from the actual runtime environment of the target function, which allows dependency verification to be performed without affecting the actual operation of the target function. In response to the environment deployment request, simulation environment platform 120 deploys at least one service involved in the target function in the corresponding simulated runtime environment. The simulated runtime environment can mimic the actual runtime environment of the target function, allowing the target function to be tested and verified without affecting its actual operation.

[0042] As an example, an environment deployment request may include information on how to deploy and configure at least one service in a simulated runtime environment. The deployment process may involve service installation, configuration file setup, resource allocation (such as CPU, memory), network configuration, etc.

[0043] In some embodiments, electronic device 110 can generate and maintain verification configuration information associated with verification request 150 for generating various requests for simulation environment platform 120, fault injection platform 130, verification configuration platform 160, and verification 140. Figure 3 illustrates a schematic diagram of an example 300 of the association between verification configuration information and multiple requests according to some embodiments of the present disclosure. In the example of Figure 3, the verification configuration information 310 associated with verification request 150 includes a running device 311 associated with the target function, first identification information 312 of the simulated running environment, fault injection scenario identification 313 and services, and interface type 314 of the target interface, etc. As an example, verification configuration information 310 can be maintained locally on electronic device 110. Users can adjust verification configuration information 310 according to actual needs, thereby adding, deleting, or modifying related information, etc. In addition, according to actual needs, verification configuration information 310 may include more information besides the various information mentioned above. For example, verification configuration information 310 may also include an identifier for operator 315. The operator 315 here can specifically refer to the user who performed adjustment operations (such as adding, deleting, or modifying) on ​​the verification configuration information 310.

[0044] In some embodiments, the electronic device 110 extracts first information from the verification configuration information 310 associated with the verification request 150, and generates an environment deployment request 320 for the simulated environment platform 120 based at least on the first information. The first information required to generate the environment deployment request 320 indicates at least one of the following: the operating device 301 associated with the target function, and / or the first identification information 312 of the simulated operating environment.

[0045] As an example, the running device 311 associated with the target function can refer to the physical device or virtual machine that actually performs the target function. The first information can indicate the identifier, data center, device type, performance specifications, etc. of these devices. The first identification information 312 can refer to the identifier of the simulated running environment associated with the target function, such as the environment name, version, configuration parameters, etc.

[0046] After extracting the initial information, the electronic device 110 generates an environment deployment request 320 based on this information and sends it to the simulation environment platform 120. The simulation environment platform 120 then responds to the environment deployment request 320 by deploying at least one service involved in the target function to the corresponding simulation environment. In this way, the electronic device 110 can flexibly adapt to the verification requirements of different target functions and environmental changes. Furthermore, as the target function to be verified changes, the verification configuration information 310 can be easily expanded and updated to support the deployment of more services in the corresponding simulation environment.

[0047] As an example, electronic device 110 can identify the version and other content of the information extracted from the verification configuration information 310, thereby extracting the latest information associated with the target function and generating an environment deployment request 320 accordingly.

[0048] In some embodiments, electronic device 110 generates an indication of operating device 321 in the simulated operating environment in the environment deployment request 320 based on operating device 311 associated with the target function. Furthermore, electronic device 110 may also generate simulated environment swimlane information 322 related to at least one service in the environment deployment request 320 based on first identification information 312. It should be noted that this information may exist alone or simultaneously in the environment deployment request 320, and the embodiments of this disclosure do not impose limitations on this.

[0049] As an example, the instructions for the running device 321 in the simulated operating environment may include, but are not limited to, indicating the server room, type (such as server, container, etc.), and specifications (such as CPU, memory, storage, etc.) of the device to be simulated in the simulated operating environment. By instructing the running device 321 in the simulated operating environment, it can be ensured that the simulation environment platform 120 can accurately reproduce the device configuration in the actual production environment, thereby providing a highly realistic simulated operating environment for the verification of the target function.

[0050] As an example, the simulation environment swimlane information 322 can refer to a unique identifier of the simulation runtime environment associated with the target function. The simulation environment swimlane information 322 is used to distinguish different simulation runtime environments. Through the simulation environment swimlane information 322, it can be ensured that the simulation environment platform 120 deploys at least one service of the target function to the correct simulation runtime environment.

[0051] In some embodiments, the environment deployment request 320 may also include further information. For example, the environment deployment request 320 may also include code branches 323 related to the simulated runtime environment, cluster information 324, deployment service information 325, and simulation environment type 326, etc. This information can instruct the simulation environment platform 120 to deploy services more precisely to the corresponding simulated runtime environment. As an example, this information may be further extracted by the electronic device 110 from the verification configuration information 310, or it may be extracted by the electronic device 110 from other channels (e.g., pipelines related to live streaming scenarios), and the embodiments of this disclosure are not limited in this regard. For example, based on the receipt of the verification request 150, the electronic device 110 generates an instruction for the fault injection simulation 326. Based on such an instruction, the simulation environment platform 120 can deploy services related to the target function in a simulated runtime environment with fault injection.

[0052] After the services involved in the target function are deployed to the corresponding simulated operating environment, the electronic device 110 sends a (213) fault injection request 330 to the fault injection platform 130 to request the injection of a fault event for the target interface in at least one of the interfaces into the simulated operating environment.

[0053] As an example, after receiving a fault injection request 330, the fault injection platform 130 can inject fault events into target interfaces for a specified simulated operating environment. These target interfaces can be one or more key interaction interfaces of the services involved in the target function.

[0054] As an example, the fault injection platform 130 can perform a series of operations to simulate fault conditions that may occur in a real production environment. These operations may include modifying network configurations to simulate network latency or packet loss, injecting erroneous data to test the error handling capabilities of the target function, or stopping service processes to simulate service downtime. Through these operations, the fault injection platform 130 can inject corresponding fault events into the target interface of the specified simulated operating environment.

[0055] In some embodiments, the electronic device 110 extracts second information from the verification configuration information 310 associated with the verification request 150, and generates a fault injection request 330 for the fault injection platform 130 based at least on the second information. The second information required to generate the fault injection request 330 indicates at least one of the following: a fault injection scenario identifier 313 associated with the target function, and / or at least one service and the interface type 314 of the target interface. The electronic device 110 then generates the fault injection request 330 based at least on the second information.

[0056] As an example, a fault injection scenario identifier 313 associated with the target function is used to uniquely identify the fault injection scenario to be performed. Each fault injection scenario can define a specific set of fault conditions. As an example, at least one service and the interface type 314 of the target interface can indicate the service and interface to be fault injected. The interface type can be, for example, an HTTP interface and / or an RPC interface, etc.

[0057] After extracting the second information, the electronic device 110 can generate a fault injection request 330 based on this information and send it to the fault injection platform 130. The fault injection platform 130 then responds to the fault injection request 330 by injecting the corresponding fault event into the target interface. In this way, the electronic device 110 can flexibly adapt to the verification requirements of different target functions and environmental changes. Furthermore, as the target functions are continuously iterated, the verification configuration information 310 can be easily expanded and updated to support more fault injection scenarios.

[0058] In some embodiments, the electronic device 110 generates an indication of the fault injection status 331 in the fault injection request 330 based on the receipt of the verification request 150. Furthermore, the electronic device 110 generates an identifier for the fault injection task 332 in the fault injection request 330 based on the fault injection scenario identifier 313. The electronic device 110 generates an indication of the fault injection method 333 in the fault injection request 330 based on the interface type of the target interface. It should be noted that this information may exist alone or simultaneously in the fault injection request 330, and the embodiments of this disclosure do not impose limitations on this.

[0059] As an example, based on the indication of fault injection state 331, fault injection platform 130 can determine to perform an injection operation on a fault event. For instance, based on the indication of fault injection state 311, fault injection platform 130 can initiate a corresponding fault injection task 332 to inject the fault event. Based on the indication of fault injection state 331, fault injection platform 130 can determine the specific operation for the fault event, thereby ensuring the flexibility and controllability of fault injection.

[0060] As an example, a fault injection task is used to specifically execute fault events. The identifier of fault injection task 332 is unique, and based on this identifier, the fault injection platform 130 can distinguish different fault injection test tasks. The identifier of fault injection task 332 can be a string, a number, or other form of identifier. Furthermore, the identifier of fault injection task 332 facilitates the tracking and recording of relevant information for each fault injection task in subsequent processes.

[0061] As an example, based on the indication of fault injection method 333, the fault injection platform 130 can determine how to inject fault events into the target interface, including interface tampering and simulated packet loss. Different interface types can correspond to different injection methods. Based on the indication of fault injection method 333, the fault injection platform 130 can accurately simulate various real-world faults, thereby greatly improving the targeting and effectiveness of fault injection.

[0062] In some embodiments, the fault injection request 330 may also include further information. For example, the environment deployment request 320 may also include fault injection counts 334, packet types 335, fault injection type tags 336, etc. This information can instruct the fault injection platform 130 to inject fault events more precisely. As an example, this information may be further extracted by the electronic device 110 from the verification configuration information 310, or it may be extracted by the electronic device 110 from other sources; the embodiments of this disclosure do not limit this.

[0063] After the fault injection is completed, the fault injection platform 130 sends a feedback message related to the fault injection to the electronic device 110. For example, the fault injection platform 130 returns (214) "fault injection successful" to the electronic device 110, or the fault injection platform 130 returns "fault injection failed" to the electronic device 110. In this way, the electronic device 110 can help determine whether to perform the next operation. In response to receiving the indication of successful fault injection from the fault injection platform 130, the electronic device 110 triggers the verification platform 140 to perform the first verification of the target function in the simulated operating environment.

[0064] In some embodiments, electronic device 110 extracts third information from verification configuration information 310 associated with verification request 150, and triggers verification platform 140 to perform a first verification on the target function in a simulated operating environment based at least on the third information. The third information required to trigger the first verification indicates at least one of the following: a fault injection scenario identifier 313 associated with the target function, and / or an interface type 314 of at least one service and the target interface. Electronic device 110 then sends a test request (215) to verification configuration platform based at least on the third information. To distinguish it from another test request (i.e., a second test request) mentioned below, the test request here will also be referred to as first test request 340. First test request 340 is configured to cause verification configuration platform 160 to select a first test case that matches first test request 340, and to cause verification configuration platform 160 to send (216) the first test case to verification platform 140 to trigger verification platform 140 to perform (217) first verification based on the first test case. To distinguish it from the other test case (i.e., the second test case) mentioned below, this test case will also be referred to as the first test case. The number of first test cases used in the first verification can be one or more. The number of second test cases used in subsequent verifications can also be one or more. The specific number can be configured according to actual needs.

[0065] It should be noted that the relevant descriptions of the fault injection scenario identifier 313 associated with the target function and the interface type 314 of at least one service and the target interface can be found in the embodiments described above, and therefore will not be repeated here.

[0066] As an example, after receiving the first test request 340, the verification configuration platform 160 can search and match its test case library based on the information provided in the request (such as fault injection scenario identifier 313, service and interface types, etc.). Once a first test case that meets the requirements is found, the verification configuration platform 160 will send these test cases to the verification platform 140.

[0067] As an example, after receiving the first test cases, the verification platform 140 performs a first verification based on these test cases. This first verification may include verification of the availability of the target function and / or the services involved in the target function. For example, the fault injection platform 130 injects a fault event related to packet loss into interface B1 of service B. During the execution of the first verification, the electronic device 110 may simulate calls to interface B1 by other services to determine the availability of these target functions and / or the services involved in the target function.

[0068] By extracting third information from the verification configuration information 310 and sending a first test request 340 to the verification configuration platform 160 based on this information, the electronic device 110 can automatically trigger and execute verification tests for specific functions. This method not only improves testing efficiency but also ensures the consistency and repeatability of verification.

[0069] In some embodiments, the electronic device 110 generates an identifier for test scenario 341 in the verification configuration platform 160 in the first test request 340 based on the fault injection scenario identifier 313. Furthermore, the electronic device 110 can also generate an indication for test method 342 in the first test request 340 based on the interface type of the target interface. It should be noted that this information can exist alone or simultaneously in the fault injection request 330, and the embodiments of this disclosure do not impose limitations on this.

[0070] As an example, based on the identifier of test scenario 341, the verification configuration platform 160 can accurately identify the test scenario 341 that the electronic device 110 wants to execute, and select the corresponding first test case and test resources accordingly. As an example, based on the instruction of test method 342, the verification configuration platform 160 can determine the specific methods, steps, parameters, etc., for conducting the test. The instruction of test method 342 facilitates the verification configuration platform 160 in accurately understanding and executing the first test request 340, and selecting an appropriate first test case.

[0071] In some embodiments, the first test request 340 may also include further information. For example, the first test request 340 may also include an indication of a test type 343 related to the first test case. For example, the electronic device 110 generates an indication for a fault injection test 343 based on the receipt of the verification request 150. Based on such an indication, the verification configuration platform 160 may use a test case related to the fault injection test as the first test case.

[0072] In some embodiments, based on the receipt of the first test request 340, the verification configuration platform 160 may supplement with more information, which can be used to enable the verification platform 140 to perform the first verification more accurately. As an example, this information may include the execution path of the first test case, etc.

[0073] After performing (217) the first verification, the verification platform 140 returns (218) the first verification result of the first verification to the electronic device 110. Based on the first verification result of the first verification received from the verification platform 140, the electronic device 110 determines the degree of dependence of at least one service on the target interface.

[0074] As an example, dependency levels can be categorized into strong and weak dependencies. A strong dependency means that the target function or the services involved in it must rely on a certain interface (also known as a strongly dependent interface) to complete its tasks. If this interface is unavailable or malfunctions, the target function or the services involved may fail to function properly or produce serious errors. In contrast, a weak dependency means that while the target function or the services involved in it may call an interface during execution, even if that interface (also known as a weakly dependent interface) is unavailable or malfunctions, the target function or the services involved in it can still continue to perform other tasks, although some functionality may be limited or affected.

[0075] In some embodiments, in response to determining that a first verification result indicates that a target function is unavailable, the electronic device 110 determines that the dependency of at least one service on the target interface is strong. In response to determining that a first verification result indicates that a target function is available, the electronic device 110 determines that the dependency of at least one service on the target interface is weak.

[0076] As an example, if the first verification result indicates that the target function is unavailable, it means that after a fault event is injected into the target interface, the target function cannot function properly or returns an error result. Electronic device 110 will recognize this and determine that the interface is a strongly dependent interface of at least one service. As an example, if the first verification result indicates that the target function is unavailable, electronic device 110 can further identify the unavailable service, and thus determine that the current target interface is a strongly dependent interface of that service. If the first verification result indicates that the target function is available, it means that after a fault event is injected into the target interface, the main function of the target function can still function properly. Electronic device 110 will recognize this and determine that the interface is a weakly dependent interface of at least one service.

[0077] In some embodiments, the electronic device 110 may send the determination result of the degree of dependency to a notification module capable of performing a notification task, thereby providing the determination result of the degree of dependency to relevant personnel.

[0078] In some embodiments, to improve verification efficiency, verification request 150 can be associated with reference dependency information. Based on the reference dependency information, electronic device 110 can employ two different strategies to test the dependency of the target function. Specifically, electronic device 110 obtains the reference dependency information associated with verification request 150. The reference dependency information indicates the expected degree of dependency of at least one service on at least one interface. In response to determining that the expected degree of dependency is strong, electronic device 110 identifies one of the at least one interfaces as the target interface. In response to determining that the expected degree of dependency is weak, electronic device 110 identifies at least one interface as the target interface.

[0079] As an example, reference dependency information can be determined based on historical data. For instance, reference dependency information can be determined based on several previous dependency verifications of the target functionality. Reference dependency information indicates the expected degree of dependency of at least one service on at least one interface.

[0080] As an example, if the reference information indicates a strong dependency, then electronic device 110 will identify one interface as the target interface during this verification process. In this way, if the interfaces involved in the target function are expected to be strongly dependent interfaces of at least one service, electronic device 110 can verify these interfaces one by one to confirm whether they are indeed strongly dependent interfaces of at least one service. If the reference information indicates a weak dependency, then electronic device 110 will identify multiple interfaces as target interfaces during this verification process. In this way, if the interfaces involved in the target function are expected to be weakly dependent interfaces of at least one service, electronic device 110 can verify these interfaces in batches. If there are at least one strongly dependent interface of at least one service, electronic device 110 can verify this batch of interfaces one by one, referring to the method described above; otherwise, electronic device 110 can identify all of these interfaces as weakly dependent interfaces of at least one service, thereby improving verification efficiency.

[0081] In addition, after the first verification is completed, trigger 201 can also send a (221) recovery request to electronic device 110 to remove the fault event injected into the target function, so that the target function can be performed on the next first verification or other verifications.

[0082] In some embodiments, in response to receiving a recovery request for a target function, electronic device 110 sends a (223) fault recovery request to fault injection platform 130 to request a halt to the injection of fault events into the simulated operating environment. Fault injection platform 130 may send feedback messages related to fault recovery to electronic device 110. For example, fault injection platform 130 may return (224) a successful fault recovery to electronic device 110, or fault recovery may return a failure to electronic device 110. In response to receiving a successful fault recovery indication from fault injection platform 130, electronic device 110 triggers verification platform 140 to perform a second verification on the target function in the simulated operating environment. Then, based on the second verification result received from verification platform 140, electronic device 110 determines whether the recovery request for the target function was successfully executed. As an example, electronic device 110 may send a (225) second test request to verification configuration platform. The second test request is configured to: cause the verification configuration platform 160 to select a second test case that matches the second test request, and cause the verification configuration platform 160 to send (226) the second test case to the verification platform 140 to trigger the verification platform 140 to perform (227) the second verification based on the second test case.

[0083] In some embodiments, after performing (227) the second verification, the verification platform 140 returns (228) the second verification result to the electronic device 110. In some embodiments, in response to determining that the second verification result indicates that the target function is unavailable, the electronic device 110 determines that the recovery request for the target function has not been successfully executed. In response to determining that the second verification result indicates that the target function is available, the electronic device 110 determines that the recovery request for the target function has been successfully executed.

[0084] As an example, the specific method and content of the fault recovery request sent by the electronic device 110 can be determined by referring to the section related to sending the fault injection request 330 mentioned above, and therefore will not be repeated here. However, it should be noted that the fault recovery request here is different from the fault injection request 330 mentioned above. Specifically, based on the receipt of the recovery request, the electronic device 110 generates an indication of the fault recovery status in the fault recovery request. In contrast to the indication of the fault injection status 311, the indication of the fault recovery status in the fault recovery request can be an indication related to "stop injecting fault". Based on the indication of the fault recovery status, the fault injection platform 130 can terminate the corresponding fault injection task 332 to stop injecting fault events.

[0085] As an example, the specific method and content of the second test request sent by the electronic device 110 to trigger the second verification can be determined with reference to the section related to the first test request 340 for triggering the first verification mentioned above, and will not be repeated here. It should be noted that the second test request here differs from the first test request 340 mentioned above. Specifically, the electronic device 110 generates an instruction for fault recovery testing based on the receipt of the recovery request. Based on this instruction, the verification configuration platform 160 can use test cases related to the fault recovery test as the second test cases.

[0086] In some embodiments, electronic device 110 sends a validity query request to the simulated operating environment. After determining that the simulated operating environment is a valid simulated operating environment, electronic device 110 then sends a fault recovery request to fault injection platform 130.

[0087] As an example, electronic device 110 sends a (222) validity query request to simulation environment platform 120. Upon receiving the validity query request, simulation environment platform 120 can perform a series of checks on the simulated operating environment to determine if it is in a valid state. These checks may include, but are not limited to, checking the configuration, resources, and whether the services involved in the target function are still deployed in the simulated environment. In this way, electronic device 110 will only send a fault recovery request to fault injection platform 130 after confirming its validity, thereby avoiding invalid operations.

[0088] As can be clearly understood from the various embodiments of this disclosure, in terms of dependency verification, the embodiments of this disclosure make the originally cumbersome and inefficient verification process efficient and automated. The embodiments of this disclosure, through electronic device 110, transform dependency verification into a fully automated process. This significantly improves verification efficiency, reducing the verification time from 60 minutes in the traditional solution to 10 minutes, achieving an 83% efficiency improvement. Furthermore, the embodiments of this disclosure save on manpower input; relevant personnel no longer need to directly participate in the verification process, and the entire verification process can be automatically triggered and executed.

[0089] Example process

[0090] Figure 4 illustrates a flowchart of an example process 400 for a dependency verification method according to some embodiments of the present disclosure. Process 400 may be implemented at an electronic device 110.

[0091] Referring to Figure 4, in block 410, in response to receiving a verification request 150 for a target function, electronic device 110 sends an environment deployment request 320 to a simulated operating environment. The verification request 150 indicates at least one service involved in the target function and at least one interface to be called by the at least one service. The environment deployment request 320 indicates the deployment of at least one service.

[0092] In some embodiments, the verification request 150 is issued at predetermined intervals.

[0093] In some embodiments, electronic device 110 extracts first information from verification configuration information 310 associated with verification request 150. The first information includes at least one of the following: a running device 311 associated with a target function, and / or first identification information 312 of a simulated operating environment. Electronic device 110 then generates an environment deployment request 320 based at least on the first information.

[0094] In some embodiments, electronic device 110 generates an indication of operating device 321 in the simulated operating environment in the environment deployment request 320 based on operating device 311 associated with a target function. And / or, electronic device 110 generates simulated environment swimlane information 322 related to at least one service in the environment deployment request 320 based on first identification information 312.

[0095] In box 420, electronic device 110 sends a fault injection request 330 to fault injection platform 130 to request the injection of a fault event for a target interface among the at least one interface into the simulated operating environment.

[0096] In some embodiments, electronic device 110 extracts second information from verification configuration information 310 associated with verification request 150. The second information indicates at least one of the following: a fault injection scenario identifier 313 associated with the target function, and / or at least one service and the interface type 314 of the target interface. Electronic device 110 then generates fault injection request 330 based at least on the second information.

[0097] In some embodiments, the electronic device 110 generates an indication of the fault injection status 331 in the fault injection request 330 based on the receipt of the verification request 150. And / or, the electronic device 110 generates an identifier for the fault injection task 332 in the fault injection request 330 based on the fault injection scenario identifier 313. And / or, the electronic device 110 generates an indication of the fault injection method 333 in the fault injection request 330 based on the interface type of the target interface.

[0098] In block 430, in response to receiving an indication of successful fault injection from the fault injection platform 130, the electronic device 110 triggers the verification platform 140 to perform a first verification of the target function in the simulated environment after the fault event is injected.

[0099] In some embodiments, electronic device 110 extracts third information from verification configuration information 310 associated with verification request 150. The third information indicates at least one of the following: a fault injection scenario identifier 313 associated with the target function, and / or an interface type 314 for at least one service and the target interface. Electronic device 110 then sends a test request to verification configuration platform 160 based at least on the third information. The test request is configured to cause verification configuration platform 160 to select a test case matching the test request, and to cause verification configuration platform 160 to send the test case to verification platform 140 to trigger verification platform 140 to perform a first verification based on the test case.

[0100] In some embodiments, the electronic device 110 generates an identifier for test scenario 341 in the verification configuration platform 160 in the test request based on the fault injection scenario identifier 313. Then, the electronic device 110 generates an indication of test method 342 in the test request based on the interface type of the target interface.

[0101] In box 440, electronic device 110 receives a first verification result from the verification platform 140, the first verification result indicating the degree of dependence of the at least one service on the target interface.

[0102] In some embodiments, in response to determining that a first verification result indicates that a target function is unavailable, the electronic device 110 determines that the dependency of at least one service on the target interface is strong. In response to determining that a first verification result indicates that a target function is available, the electronic device 110 determines that the dependency of at least one service on the target interface is weak.

[0103] In some embodiments, electronic device 110 obtains reference dependency information associated with verification request 150, the reference dependency information indicating the expected degree of dependency of at least one service on at least one interface. In response to determining that the expected degree of dependency is strong, electronic device 110 identifies one of the at least one interfaces as a target interface. In response to determining that the expected degree of dependency is weak, electronic device 110 identifies at least one interface as a target interface.

[0104] In some embodiments, in response to receiving a recovery request for a target function, electronic device 110 sends a fault recovery request to fault injection platform 130 to request a halt to the injection of fault events into the simulated operating environment. In response to receiving an indication of successful fault recovery from fault injection platform 130, electronic device 110 triggers verification platform 140 to perform a second verification on the target function in the simulated operating environment. Then, based on the second verification result received from verification platform 140, electronic device 110 determines whether the recovery request for the target function was successfully executed.

[0105] In some embodiments, electronic device 110 sends a validity query request to the simulated operating environment. In response to determining that the simulated operating environment is a valid simulated operating environment, electronic device 110 sends a fault recovery request to fault injection platform 130.

[0106] In some embodiments, in response to determining that a second verification result indicates that a target function is unavailable, electronic device 110 determines that a recovery request for the target function has not been successfully executed. In response to determining that a second verification result indicates that a target function is available, electronic device 110 determines that a recovery request for the target function has been successfully executed.

[0107] Example devices and equipment

[0108] Embodiments of this disclosure also provide corresponding apparatus for implementing the methods or processes described above. Figure 5 shows a schematic structural block diagram of an apparatus 500 for dependency verification according to some embodiments of this disclosure. The apparatus 500 may be implemented as or included in electronic device 110. The various modules / components in the apparatus 500 may be implemented by hardware, software, firmware, or any combination thereof.

[0109] Referring to Figure 5, the apparatus 500 includes a first sending module 510, a second sending module 520, a verification triggering module 530, and a dependency determination module 540. The first sending module 510 is configured to, in response to receiving a verification request 150 for a target function, send an environment deployment request 320 to the simulated runtime environment. The verification request 150 indicates at least one service involved in the target function and at least one interface to be called by the at least one service. The environment deployment request 320 indicates the deployment of the at least one service. The second sending module 520 is configured to send a fault injection request 330 to a fault injection platform 130 to request the injection of a fault event for a target interface among the at least one interface into the simulated runtime environment. The verification triggering module 530 is configured to, in response to receiving an indication of successful fault injection from the fault injection platform 130, trigger the verification platform 140 to perform a first verification on the target function in the simulated runtime environment. The dependency determination module 540 is configured to, based on the first verification result received from the verification platform 140, determine the dependency degree of the at least one service on the target interface.

[0110] In some embodiments, the first sending module 510 is further configured to: extract first information from the verification configuration information 310 associated with the verification request 150, wherein the first information indicates at least one of the following: the operating device 311 associated with the target function, and / or the first identification information 312 of the simulated operating environment; and generate an environment deployment request 320 based at least on the first information.

[0111] In some embodiments, the first sending module 510 is further configured to: generate an indication of the operating device 321 in the simulated operating environment in the environment deployment request 320 based on the operating device 311 associated with the target function; and / or generate simulated operating environment swimlane information associated with at least one service in the environment deployment request 320 based on the first identification information 312.

[0112] In some embodiments, the second sending module 520 is further configured to: extract second information from the verification configuration information 310 associated with the verification request 150, wherein the second information indicates at least one of the following: a fault injection scenario identifier 313 associated with the target function, and / or an interface type 314 of at least one service and the target interface; and generate a fault injection request 330 based at least on the second information.

[0113] In some embodiments, the second sending module 520 is further configured to: generate an indication of fault injection status 331 in the fault injection request 330 based on the receipt of the verification request 150; and / or generate an identifier of fault injection task 332 in the fault injection request 330 based on the fault injection scenario identifier 313; and / or generate an indication of fault injection method 333 in the fault injection request 330 based on the interface type of the target interface.

[0114] In some embodiments, the verification triggering module 530 is further configured to: extract third information from the verification configuration information 310 associated with the verification request 150, wherein the third information indicates at least one of the following: a fault injection scenario identifier 313 associated with the target function, and / or an interface type 314 of at least one service and the target interface; and send a test request to the verification configuration platform 160 based at least on the third information, wherein the test request is configured to: cause the verification configuration platform 160 to select a test case that matches the test request, and cause the verification configuration platform 160 to send the test case to the verification platform 140 to trigger the verification platform 140 to perform a first verification based on the test case.

[0115] In some embodiments, the verification triggering module 530 is further configured to: generate an identifier for test scenario 341 in verification configuration platform 160 in the test request based on fault injection scenario identifier 313; and generate an indication for test method 342 in the test request based on the interface type of the target interface.

[0116] In some embodiments, the dependency determination module 540 is further configured to: in response to determining that the first verification result indicates that the target function is unavailable, determine that the dependency of at least one service on the target interface is a strong dependency; and in response to determining that the first verification result indicates that the target function is available, determine that the dependency of at least one service on the target interface is a weak dependency.

[0117] In some embodiments, the apparatus 500 further includes a target interface determination module. The target interface determination module is configured to: acquire reference dependency information associated with the verification request 150, the reference dependency information indicating the expected degree of dependency of at least one service on at least one interface; determine one of the at least one interfaces as a target interface in response to determining that the expected degree of dependency is a strong dependency; and determine at least one interface as a target interface in response to determining that the expected degree of dependency is a weak dependency.

[0118] In some embodiments, the apparatus 500 further includes a fault recovery request sending module. The fault recovery request sending module is configured to: in response to receiving a recovery request for a target function, send a fault recovery request to the fault injection platform 130 to request a halt to the injection of fault events into the simulated operating environment; in response to receiving an indication of successful fault recovery from the fault injection platform 130, trigger the verification platform 140 to perform a second verification on the target function in the simulated operating environment; and based on the second verification result received from the verification platform 140, determine whether the recovery request for the target function was successfully executed.

[0119] In some embodiments, the fault recovery request sending module is further configured to: send a validity query request to the simulated operating environment; and, in response to determining that the simulated operating environment is a valid simulated operating environment, send a fault recovery request to the fault injection platform 130.

[0120] In some embodiments, the fault recovery request sending module is further configured to: determine that the recovery request for the target function was not successfully executed in response to determining that the second verification result indicates that the target function is unavailable; and determine that the recovery request for the target function was successfully executed in response to determining that the second verification result indicates that the target function is available.

[0121] In some embodiments, the verification request 150 is issued at predetermined intervals.

[0122] Figure 6 shows a block diagram of an electronic device 600 in which one or more embodiments of the present disclosure may be implemented. This electronic device 600 may, for example, be used to implement the electronic device 110 shown in Figure 1. It should be understood that the electronic device 600 shown in Figure 6 is merely exemplary and should not constitute any limitation on the functionality and scope of the embodiments described herein.

[0123] Referring to Figure 6, the electronic device 600 is in the form of a general-purpose electronic device. Components of the electronic device 600 may include, but are not limited to, one or more processors or processing units 610, memory 620, storage device 630, one or more communication units 640, one or more input devices 650, and one or more output devices 660. The processing unit 610 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 620. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of the electronic device 600.

[0124] Electronic device 600 typically includes multiple computer storage media. Such media can be any available media accessible to electronic device 600, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 620 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 630 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media capable of storing information and / or data and accessible within electronic device 600.

[0125] Electronic device 600 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 6, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks may be provided. In these cases, each drive may be connected to a bus (not shown) via one or more data media interfaces. Memory 620 may include computer program product 625 having one or more program modules configured to perform various methods or actions of various embodiments of the present disclosure.

[0126] The communication unit 640 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 600 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 600 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0127] Input device 650 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 660 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 600 can also communicate as needed with one or more external devices (not shown) via communication unit 640. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 600, or with any device that enables electronic device 600 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interface (not shown).

[0128] According to an exemplary implementation of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to an exemplary implementation of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0129] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0130] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0131] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0133] Various implementations of this disclosure have been described above. The foregoing description is exemplary and not exhaustive, nor is it limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is determined to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for dependency verification, comprising: In response to receiving a verification request for a target function, an environment deployment request is sent to the simulated runtime environment, wherein the verification request indicates at least one service involved in the target function and at least one interface to be called by the at least one service, and the environment deployment request indicates the deployment of the at least one service; Send a fault injection request to the fault injection platform to request the injection of a fault event targeting one of the at least one interfaces into the simulated operating environment; In response to receiving an indication of successful fault injection from the fault injection platform, the verification platform is triggered to perform a first verification of the target function in the simulated operating environment; as well as Based on the first verification result received from the verification platform, the degree of dependence of the at least one service on the target interface is determined.

2. The method according to claim 1, wherein the environment deployment request is generated in the following manner: First information is extracted from the verification configuration information associated with the verification request, wherein the first information indicates at least one of the following: Operating devices associated with the target function, and / or The first identification information of the simulated operating environment; and The environment deployment request is generated based at least on the first information.

3. The method of claim 2, wherein generating the environment deployment request is based at least on the first information, comprising at least one of the following: Based on the operating device associated with the target function, generate an indication of the operating device in the simulated operating environment in the environment deployment request, and / or Based on the first identification information, simulated environment swimlane information related to the at least one service in the environment deployment request is generated.

4. The method of claim 1, wherein the fault injection request is generated in the following manner: Second information is extracted from the verification configuration information associated with the verification request, wherein the second information indicates at least one of the following: Fault injection scenario identifiers associated with the target function, and / or The interface type of the at least one service and the target interface; and The fault injection request is generated based at least on the second information.

5. The method of claim 4, wherein generating the fault injection request is based at least on the second information, comprising at least one of the following: Based on the receipt of the verification request, an indication of the fault injection status in the fault injection request is generated; and / or Based on the fault injection scenario identifier, generate an identifier for the fault injection task in the fault injection request; and / or Based on the interface type of the target interface, an indication of the fault injection method is generated in the fault injection request.

6. The method according to claim 1, wherein triggering the verification platform to perform a first verification of the target function in the simulated operating environment comprises: Third information is extracted from the verification configuration information associated with the verification request, wherein the third information indicates at least one of the following: Fault injection scenario identifiers associated with the target function, and / or The interface type of the at least one service and the target interface; and Based at least on the third information, a test request is sent to the verification configuration platform, wherein the test request is configured as follows: The verification configuration platform selects test cases that match the test request, and The verification configuration platform sends the test case to the verification platform, thereby triggering the verification platform to execute the first verification based on the test case.

7. The method of claim 6, wherein the test request is generated in the following manner: Based on the fault injection scenario identifier, an identifier for the test scenario in the verification configuration platform is generated in the test request; and Based on the interface type of the target interface, the test request is generated to indicate the test method.

8. The method of claim 1, wherein determining the dependency of the at least one service on the target interface comprises: In response to determining that the first verification result indicates that the target function is unavailable, the dependency degree of the at least one service on the target interface is determined to be a strong dependency degree; or In response to determining that the first verification result indicates that the target function is available, the dependency of the at least one service on the target interface is determined to be a weak dependency.

9. The method according to claim 1, further comprising: Obtain reference dependency information associated with the verification request, the reference dependency information indicating the expected degree of dependency of the at least one service on the at least one interface; In response to determining that the expected degree of dependency is a strong degree of dependency, one of the at least one interfaces is determined as the target interface; as well as In response to determining that the expected dependency level is a weak dependency level, the at least one interface is identified as the target interface.

10. The method according to claim 1, further comprising: In response to receiving a recovery request for the target function, a fault recovery request is sent to the fault injection platform. A request is made to stop injecting the fault events into the simulated operating environment. In response to receiving an indication of successful fault recovery from the fault injection platform, the verification platform is triggered to perform a second verification of the target function in the simulated operating environment; as well as Based on the second verification result received from the verification platform, it is determined whether the recovery request for the target function was successfully executed.

11. The method of claim 10, wherein sending a fault recovery request to the fault injection platform includes: Send a validity query request to the simulated operating environment; as well as In response to determining that the simulated operating environment is a valid simulated operating environment, the fault recovery request is sent to the fault injection platform.

12. The method of claim 10, wherein determining whether a recovery request for the target function was successfully executed comprises: In response to determining that the second verification result indicates that the target function is unavailable, it is determined that the recovery request for the target function was not successfully executed; as well as In response to determining that the second verification result indicates that the target function is available, it is determined that the recovery request for the target function has been successfully executed.

13. The method of claim 1, wherein the verification request is issued at predetermined intervals.

14. An apparatus for dependency verification, comprising: An environment deployment request sending module is configured to send an environment deployment request to a simulated runtime environment in response to receiving a verification request for a target function, wherein the verification request indicates at least one service involved in the target function and at least one interface to be called by the at least one service, and the environment deployment request indicates the deployment of the at least one service. The fault injection request sending module is configured to send a fault injection request to the fault injection platform to request the injection of a fault event for a target interface among the at least one interface into the simulated operating environment. The verification trigger module is configured to trigger the verification platform to perform a first verification of the target function in the simulated operating environment in response to receiving an indication of successful fault injection from the fault injection platform; as well as The dependency determination module is configured to determine the dependency of the at least one service on the target interface based on the first verification result received from the first verification platform.

15. An electronic device comprising: At least one processing unit; as well as At least one memory, coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 13 when executed by the at least one processing unit.

16. A computer-readable storage medium having a computer program stored thereon, the computer program being executable by a processor to implement the method according to any one of claims 1 to 13.

17. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method according to any one of claims 1 to 13.

Images