Test scene generation method and device

Abstract

The embodiment of the invention provides a test scene generation method and related equipment / products, and relates to the field of software testing. The method comprises the steps that a data request of a target business scene is received, the target business scene is associated with one or more services, the one or more services are pre-configured with dyeing instances, and the dyeing instances have dyeing identifications; determining a target data request based on the data request, and forwarding the target data request to a dyeing instance of one or more services; wherein the target data request carries a dyeing identifier; acquiring the traffic of the dyeing instances of one or more services to obtain a traffic set; the traffic is generated based on the target data request; and obtaining a plurality of test cases based on the flow set conversion, wherein the plurality of test cases are used for constructing a test scene for the target business scene. According to the technical scheme, the test scene containing the complete operation chain can be generated, the influence on the normal environment is relieved, and the labor cost for manually compiling the test scene is saved.

Description

Technical Field

[0001] Embodiments of the present application relate to the technical field of software testing, and in particular, to a method, device, computer device, computer-readable storage medium, and computer program product for generating test scenarios. Background Art

[0002] With the development of software development technology, writing test scenarios has become increasingly important. By constructing a test environment for specific business scenarios for system testing, the reliability and stability of the system in a real environment can be ensured. However, the existing test scenario generation still relies on manual writing and is prone to interfering with the normal operation of the system.

[0003] It should be noted that the above content is not necessarily prior art and is not used to limit the patent protection scope of the present application. Summary of the Invention

[0004] Embodiments of the present application provide a method, device, computer device, computer-readable storage medium, and computer program product for generating test scenarios to solve or alleviate one or more of the above technical problems.

[0005] One aspect of embodiments of the present application provides a method for generating test scenarios, the method including: Receiving a data request for a target business scenario, the target business scenario being associated with one or more services, the one or more services being pre-configured with dyeing instances, the dyeing instances having dyeing identifiers; Determining a target data request based on the data request and forwarding the target data request to the dyeing instances of the one or more services; wherein, the target data request carries the dyeing identifier; Obtaining the traffic of the dyeing instances of the one or more services to obtain a traffic set; wherein, the traffic is generated based on the target data request; Converting the traffic set into a plurality of test cases, the plurality of test cases being used to construct a test scenario for the target business scenario.

[0006] Optionally, receiving a data request for a target business scenario includes: Receiving a data request associated with the one or more services, the data request coming from a target object; Based on the data request, determining the type of the target object, the type including: test type, or non-test type; In the case where the target object is of the test type, adding the dyeing identifier to the data request.

[0007] Optionally, the one or more services are further configured with a benchmark instance; correspondingly, determining a target data request based on the data request and forwarding the target data request to the dyed instances of the one or more services includes: Determining whether the data request carries the dyeing identifier; When the data request carries the dyeing identifier, determining the data request as the target data request and forwarding the target data request to the dyed instances of the one or more services; When the data request does not carry the dyeing identifier, forwarding the data request to the benchmark instance of the one or more services.

[0008] Optionally, each dyed instance has an associated container, and the associated container is used to record the traffic of the corresponding dyed instance; Correspondingly, obtaining the traffic of the dyed instances of the one or more services to obtain a traffic set includes: Obtaining the traffic of the dyed instances of the one or more services based on the associated container of each dyed instance.

[0009] Optionally, the associated container is further used to: associate and store the traffic with the dyeing identifier in a preset database; Correspondingly, obtaining the traffic of the dyed instances of the one or more services to obtain a traffic set includes: Obtaining the traffic of the dyed instances of the one or more services from the preset database according to the dyeing identifier.

[0010] Optionally, each service provides one or more interfaces; correspondingly, converting a plurality of test cases based on the traffic set, and the plurality of test cases are used to construct a test scenario for the target business scenario, including: Determining the corresponding services of each interface; Determining the traffic of the dyed instances of the corresponding service from the traffic set, and determining the preliminary screening traffic of each interface based on the traffic of the dyed instances of the corresponding service; Converting the preliminary screening traffic of each interface into a test case for the corresponding interface; Composing a test scenario for the target business scenario according to the test cases of each interface.

[0011] Optionally, the traffic includes the target data request and the data response to the target data request, and the test case is converted based on the traffic.

[0012] Another aspect of the embodiments of the present application provides a test scenario generation device, and the device includes: A receiving module, configured to receive a data request for a target service scenario, where the target service scenario is associated with one or more services, and the one or more services are pre-configured with dyeing instances, and the dyeing instances have dyeing identifiers; A forwarding module, configured to determine a target data request based on the data request and forward the target data request to the dyeing instances of the one or more services; wherein, the target data request carries the dyeing identifier; An obtaining module, configured to obtain the traffic of the dyeing instances of the one or more services to obtain a traffic set; wherein, the traffic is generated based on the target data request; A constructing module, configured to convert the traffic set into a plurality of test cases, and the plurality of test cases are used to construct a test scenario for the target service scenario.

[0013] Another aspect of the embodiments of the present application provides a computer device, including: At least one processor; and A memory communicatively connected to the at least one processor; Wherein: the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method as described above.

[0014] Another aspect of the embodiments of the present application provides a computer-readable storage medium, where computer instructions are stored in the computer-readable storage medium, and when the computer instructions are executed by a processor, the method as described above is implemented.

[0015] Another aspect of the embodiments of the present application provides a computer program product, including a computer program, and when the computer program is executed by a processor, the method as described above is implemented.

[0016] The embodiments of the present application adopting the above technical solutions may include the following advantages: Pre-configure one or more services associated with the target business scenario with dyed instances having dyed identifiers, and construct a dyed environment (test environment) that is completely isolated from and does not interfere with the normal environment. Receive a data request for the target business scenario, and determine a target data request carrying a dyed identifier from the data request. Forward the target data request to the dyed instances of one or more services. Obtain the traffic of the dyed instances of one or more services to obtain a traffic set. Convert the traffic set into multiple test cases, where the multiple test cases are used to construct a test environment for the target business scenario. It can be seen that in the embodiments of the present application, by establishing a complete set of test environments (dyed instances of one or more services) containing a unified identifier (dyed identifier), the target data request only circulates in this set of test environments, which can mitigate the impact on the normal environment. By collecting the traffic of each dyed instance and converting it to obtain multiple test cases, a test scenario containing a complete operation chain can be generated, saving the labor cost of manually writing test scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings exemplarily show embodiments and form a part of the description, and are used together with the written description of the description to explain the exemplary embodiments of the embodiments. The shown embodiments are only for illustrative purposes and do not limit the scope of the claims. In all the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0018] Figure 1 Schematically shows a flowchart of a test scenario generation method according to Embodiment 1 of the present application; Figure 2 Schematically shows a flowchart of a test scenario generation method according to Embodiment 1 of the present application; Figure 3 Schematically shows Figure 1 a sub-step flowchart of step S100 therein; Figure 4 Schematically shows Figure 1 a sub-step flowchart of step S102 therein; Figure 5 Schematically shows Figure 1 a sub-step flowchart of step S106 therein; Figure 6 Schematically shows a block diagram of a test scenario generation device according to Embodiment 2 of the present application; and Figure 7 Schematically shows a schematic diagram of the hardware architecture of a computer device according to Embodiment 3 of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts shall fall within the scope of protection of the present application.

[0020] It should be noted that in the embodiments of the present application, the descriptions involving "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one such feature. Additionally, the technical solutions between various embodiments can be combined with each other, but it must be based on the ability of those of ordinary skill in the art to implement. When the combination of technical solutions results in contradictions or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by the present application.

[0021] In the description of the present application, it should be understood that the numerical labels before the steps do not identify the order of execution of the steps, but are only used to facilitate the description of the present application and distinguish each step. Therefore, it cannot be understood as a limitation to the present application.

[0022] First, the following provides the term explanations related to the present application: K8s (Kubernetes): An orchestration and management system for containers.

[0023] Pod: The smallest management unit in K8s, which is a combination of one or more containers.

[0024] Microservices: A software development technology, which is a variant of the service-oriented architecture (SOA, Service-Oriented Architecture). A single application is divided into a group of small services that cooperate and coordinate with each other to provide the final value. Each service runs in its independent process, and lightweight communication mechanisms (such as HTTP protocol, gRPC protocol) are used to communicate between services.

[0025] ES (Elasticsearch): A distributed search and analysis engine built on top of Lucene, widely used in real-time data search, log analysis, full-text search, and big data analysis scenarios.

[0026] API (Application Programming Interface): Application Programming Interface.

[0027] APP (Application): Application program.

[0028] Secondly, to facilitate the understanding of the technical solutions provided by the embodiments of the present application by those skilled in the art, the related technologies are described below: With the development of software development technology, writing test scenarios has become increasingly important. By constructing a test environment for specific business scenarios for system testing, the reliability and stability of the system in the real environment can be ensured.

[0029] However, the applicant has learned that the generation of related test scenarios still relies on manual writing and is prone to interfering with the normal operation of the system.

[0030] For this reason, the embodiments of the present application provide a technical solution for generating test scenarios. In this technical solution: (1) The concept of a dyed environment is proposed. When a microservice is released, it can choose to release a dyed instance with a dyed identifier. Add a specific KEY with a value of the dyed identifier to the request header. In this way, when a request hits a certain service, it will be preferentially forwarded to the dyed instance with the dyed identifier. After all microservices on which the business scenario depends release a dyed instance with the same dyed identifier, a complete and independent dyed environment can be obtained, which plays a role in environment isolation. (2) Use the means of traffic recording to generate API test cases and further combine them into test scenarios. Deploy an accompanying container Pod capable of recording traffic in each dyed instance through K8s to obtain all traffic hitting the corresponding dyed instance. Filter out all traffic according to the dyed identifier, that is, all operations in the dyed environment, convert the traffic into test cases, and then further filter these test cases according to business requirements, and finally generate an expected test scenario. See the following for details.

[0031] The technical solutions of the present application are introduced below through multiple embodiments. It should be noted that these embodiments can be implemented in many different forms and should not be construed as being limited only to the embodiments described herein.

[0032] Embodiment 1 Figure 1 Schematically shows a flowchart of a test scenario generation method according to Embodiment 1 of the present application.

[0033] As Figure 1 shown, the test scenario generation method may include steps S100 to S106, where: Step S100, receiving a data request for a target business scenario, the target business scenario being associated with one or more services, and the one or more services being pre-configured with dyed instances, the dyed instances having dyed identifiers.

[0034] Step S102: Determine a target data request based on the data request, and forward the target data request to the colored instances of the one or more services; wherein, the target data request carries the coloring identifier.

[0035] Step S104: Obtain the traffic of the colored instances of the one or more services to obtain a traffic set; wherein, the traffic is generated based on the target data request.

[0036] Step S106: Convert a plurality of test cases based on the traffic set, and the plurality of test cases are used to construct a test scenario for the target business scenario.

[0037] The test scenario generation method provided in this embodiment pre-configures colored instances with coloring identifiers for one or more services associated with the target business scenario, and constructs a colored environment (test environment) that is completely isolated from and does not interfere with the normal environment. Receive a data request for the target business scenario, and determine a target data request carrying a coloring identifier from the data request. Forward the target data request to the colored instances of one or more services. Obtain the traffic of the colored instances of one or more services to obtain a traffic set. Convert the traffic set into a plurality of test cases, wherein the plurality of test cases are used to construct a test environment for the target business scenario. It can be seen that in the embodiment of the present application, by establishing a complete set of test environments (colored instances of one or more services) containing a unified identifier (coloring identifier), the target data request only circulates in this set of test environments, which can mitigate the impact on the normal environment. By collecting the traffic of each colored instance and converting it into a plurality of test cases, a test scenario including a complete operation chain can be generated, saving the labor cost of manually writing test scenarios.

[0038] The following combines Figure 1 to elaborate in detail on each step in steps S100 to S106 and optional other steps.

[0039] Step S100 , receive a data request for the target business scenario, the target business scenario is associated with one or more services, and the one or more services are pre-configured with colored instances, and the colored instances have coloring identifiers.

[0040] A business scenario may include a series of operations carried out to achieve a specific business goal. For example, a business scenario may be a user purchasing a product. This business scenario may involve multiple user operations: user login, product browsing, adding to a shopping cart, viewing a shopping cart, submitting an order, and payment. These operations can be completed through an e-commerce platform, ultimately achieving the business goal of the user purchasing a product. As a single application, the e-commerce platform provides functions such as user login, product browsing, shopping cart, order management, and payment. The single application can be split into multiple independent services (microservices) based on the functions, such as: user service, for user registration, login, and permission management; product service, for managing product information, classification, and search; shopping cart service, for managing the user's shopping cart; order service, for order creation and query; payment service, for processing payment processes, etc. That is, a business scenario may involve one or more services. For example, a user viewing an order may only involve the order service, while a user purchasing a product involves the above series of services.

[0041] The target business scenario may be a business scenario for which a test scenario needs to be constructed. For example, all services involved in the target business scenario may be determined, such as Figure 2 Service A, service B, etc. are shown. A dyeing identifier is determined in advance to ensure that all services publish dyeing instances with the dyeing identifier, thereby building a dyeing environment (test environment) consisting of one or more dyeing instances.

[0042] In this embodiment, by pre-configuring dyeing instances with the same dyeing identifier for all services that the target business scenario depends on, a complete and independent dyeing environment can be obtained, which plays a role in isolating from the normal environment to avoid affecting the normal operation of the system.

[0043] In actual applications, the data request of the target business scenario can be received through the API Gateway service. The data request can be a series of operations performed by the user in the target business scenario, such as logging in, browsing products, placing orders, etc. The data request can come from various users. To ensure the reliability of the test scenario and alleviate interference with other users, the data request can be updated according to the source of the data request to facilitate the generation of subsequent test environments. An exemplary solution is provided below.

[0044] In an optional embodiment, if Figure 3 As shown, step S100 may include: Step S300: receiving a data request associated with the one or more services, wherein the data request comes from a target object.

[0045] Step S302: determining the type of the target object based on the data request, where the type includes: a test type or a non-test type.

[0046] Step S304, when the target object is of the test type, add the coloring identifier to the data request.

[0047] The target object can be each user, and the data request can include a request path, a request header, a request body, etc. It should be noted that the data requests in the embodiments of this application are all obtained on the premise of compliance and with the consent of the user. As Figure 2 shown, when the gateway service receives a data request, it can extract the type identifier of the target object from the data request. The type of the target object can be a test type or a non-test type. It should be noted that the target object of the test type refers to an internal user who logs in to a test account to complete the test operation of a certain business scenario, rather than an ordinary APP user. When it is determined that the target object is of the test type, a special request header such as x-color: test can be added to the request header of the data request, where the value of test can be the coloring identifier. The special request header can be used to inform the downstream traffic forwarding service that such data requests need to be preferentially forwarded to the corresponding colored instances of the service.

[0048] In this embodiment, by adding the coloring identifier to the data request, it can be ensured that the data requests of test users can be preferentially forwarded to the colored environment, thereby isolating test users from ordinary users, and further improving the reliability and accuracy of the subsequent generated test scenarios.

[0049] Step S102 , determine the target data request based on the data request, and forward the target data request to the colored instances of the one or more services; wherein, the target data request carries the coloring identifier.

[0050] As Figure 2 shown, when the traffic forwarding service receives the data request sent by the gateway service, it can determine whether the data request is the target data request based on whether the data request carries the coloring identifier, and forward the target data request to the colored instances of one or more services. The following provides an exemplary solution.

[0051] In an alternative embodiment, one or more services may also be configured with benchmark instances. As Figure 4 shown, step S102 may include: Step S400, determine whether the data request carries the coloring identifier.

[0052] Step S402, when the data request carries the coloring identifier, determine the data request as the target data request, and forward the target data request to the colored instances of the one or more services.

[0053] Step S404, in the case where the data request does not carry the coloring identifier, forward the data request to the benchmark instances of the one or more services.

[0054] Exemplarily, when the traffic forwarding service receives a data request sent by the gateway service, it can parse the data request to determine whether it carries a coloring identifier. If the data request carries a coloring identifier, it can be determined as a target data request. Forward the target data request to the colored instances of one or more services. If the data request does not carry a coloring identifier, the data request can be forwarded to the benchmark instances of one or more services. In some embodiments, if the data request carries a coloring identifier but there is no corresponding colored instance, the data request can be forwarded to the benchmark instances of one or more services.

[0055] In this embodiment, according to whether the data request carries a coloring identifier, the data request is intelligently forwarded to the colored instance or the benchmark instance, thereby optimizing traffic management and ensuring complete isolation between the test environment and other environments (normal production environment) without interference.

[0056] Step S104 , obtain the traffic of the colored instances of the one or more services to obtain a traffic set; wherein, the traffic is generated based on the target data request.

[0057] Exemplarily, a traffic monitoring tool can be used to obtain the traffic of the colored instances of one or more services to obtain a traffic set, wherein the traffic can be generated based on the target data request. In an alternative embodiment, the traffic can include the target data requests sent to the colored instances and the data desired by the colored instances in response to the target data requests (such as the return body). One traffic can be used to generate a test case, which can simulate real user operations to verify whether the system can respond correctly. The following provides an exemplary solution.

[0058] In an alternative embodiment, each colored instance can have an associated container, wherein the associated container can be used to record the traffic of the corresponding colored instance. Correspondingly, step S104 can include: obtaining the traffic of the colored instances of the one or more services based on the associated containers of each colored instance.

[0059] Exemplarily, as Figure 2 shown, each colored instance can be configured with an associated container, and the associated container can be responsible for recording the traffic of the corresponding colored instance. After the colored instance is started, the associated container can be started simultaneously and start listening to the network card of the colored instance, caching all the traffic sent to the corresponding colored instance in the associated container. Through the associated containers of each colored instance, the traffic of the colored instances of one or more services can be obtained.

[0060] In this embodiment, by recording the traffic hitting the staining instance through the companion container, the traffic can be accurately captured, improving the reliability and consistency of the generated test environment.

[0061] In an alternative embodiment, the companion container can also be used to: associate and store the traffic with the staining identifier in a preset database. Correspondingly, step S104 may include: obtaining the traffic of the staining instances of the one or more services from the preset database according to the staining identifier.

[0062] Exemplarily, as Figure 2 shown, when the staining instance is started, the companion container can be started simultaneously to monitor the network card of the staining instance, and upload all the traffic hitting the corresponding staining instance to a preset database (such as ES, MySQL, etc.) for persistent storage. For the convenience of subsequent traffic screening, the traffic and the staining identifier can be associated and stored. For example, before uploading the traffic to ES, the staining identifier of the staining instance can be obtained first, and the staining identifier can be used as the keyword field in ES and persisted together with the traffic. In some embodiments, as Figure 2 shown, a traffic recording platform can also be provided. After internal users log in to the test account (i.e., the target object of the test type) and complete all test operations (send data requests) in the target business scenario, they can access the traffic recording platform. Through the staining identifier, obtain the traffic of the staining instances of the one or more services persisted in ES. In practical applications, internal users can further screen the traffic according to business requirements to obtain a traffic set, and finally upload the traffic set to the interface test platform.

[0063] In this embodiment, the staining instances of all the microservices related to the target business scenario use the same staining identifier. Therefore, the traffic of all the microservices in the corresponding staining environment can be quickly filtered out on the traffic recording platform using the staining identifier, and then the traffic can be imported into the interface test platform to generate a test scenario including the user's complete operation chain.

[0064] Step S106 , convert a plurality of test cases based on the traffic set, and the plurality of test cases are used to construct a test scenario for the target business scenario.

[0065] Exemplarily, after receiving the traffic set uploaded by the traffic recording platform, the interface testing platform can further convert the traffic in the traffic set. Since the recorded real traffic can include a large amount of key information, such as: request path, request header, request body, return body, etc., a certain traffic can be directly converted into a test case for the corresponding interface on the interface testing platform. After all the traffic in the traffic set is converted into test cases, a test scenario capable of testing the target business scenario can be formed based on these test cases. An exemplary solution is provided below.

[0066] In an alternative embodiment, each service provides one or more interfaces. Correspondingly, as Figure 5 shown, step S106 may include: Step S500, determining the corresponding services of each interface.

[0067] Step S502, determining the traffic of the staining instances of the corresponding service from the traffic set, and determining the preliminary screening traffic of each interface based on the traffic of the staining instances of the corresponding service.

[0068] Step S504, converting the preliminary screening traffic of each interface into a test case for the corresponding interface.

[0069] Step S506, forming a test scenario for the target business scenario according to the test cases of each interface.

[0070] Exemplarily, the corresponding services of each interface can be determined. The traffic of the staining instances of the corresponding service is obtained from the traffic set. Based on the information of the traffic, such as the request path, request header, request body, etc., the traffic of the corresponding interface, that is, the preliminary screening traffic, is determined from the traffic of the staining instances of the corresponding service. The preliminary screening traffic of each interface is converted into a test case for the corresponding interface. According to the test cases of each interface, a test scenario for the target business scenario can be formed.

[0071] In this embodiment, determining the traffic of each interface based on the traffic of the staining instances, generating test cases for each interface, and combining them into a complete test scenario can be used to test the reliability and stability of the target business scenario and improve the test coverage. The test scenario is automatically generated without manual writing, which can reduce labor costs and improve development and test efficiency.

[0072] To make the present application easier to understand, the following is combined with Figure 2 to provide an exemplary application.

[0073] This exemplary application can have five key components: gateway service, traffic forwarding service, staining environment, traffic recording platform, and interface testing platform.

[0074] S1: Gateway Service: Receive the data request of the target object and extract the type identifier of the target object. After determining that the target object is of the test type, add a special request header such as x-color: test to the request header of the data request, where the value of test can be a coloring identifier corresponding to the coloring environment. The special request header is used to inform the downstream traffic forwarding service that such data requests need to be preferentially forwarded to the corresponding colored instance of the service.

[0075] Among them, the coloring environment is a test environment composed of colored instances of one or more microservices. Sort out all the microservices required in the test process of the target business scenario (such as Service A, Service B, etc.), determine a coloring identifier, and ensure that all microservices have published colored instances with this coloring identifier.

[0076] S2: Traffic Forwarding Service: Receive the data request sent by the gateway service. If there is no coloring identifier in the data request or there is no colored instance corresponding to the coloring identifier, forward the data request to the baseline instance of the service. If the data request carries a coloring identifier, determine it as the target data request and forward it to the colored instance of the service.

[0077] After the colored instance starts, the accompanying container responsible for recording traffic starts at the same time, starts listening to the network card of the colored instance, and uploads all the traffic hitting the corresponding colored instance to ES for persistent storage. To facilitate subsequent screening of traffic, before uploading to ES, the coloring identifier of the colored instance can be obtained first, and the coloring identifier can be used as the keyword field in ES and persisted together with the traffic.

[0078] S4: Traffic Recording Platform: Internal users can access the traffic recording platform after logging in to the test account and completing the test operations of the target business scenario to obtain all the traffic persisted in ES. Since the colored instances of all relevant microservices use the same coloring identifier, it is possible to filter out the traffic of all microservices in the corresponding coloring environment on the traffic recording platform using the coloring identifier. Internal users can also further screen the traffic according to actual business needs to obtain a traffic set, and finally upload the traffic set to the interface test platform.

[0079] S5: Interface Test Platform: After receiving the traffic set uploaded by the traffic recording platform, further transform the traffic in the traffic set. Since the recorded real traffic includes a large amount of key information, such as: request path, request header, request body, response body, etc., it is possible to directly convert a piece of traffic into a test case for the corresponding interface on the interface test platform. After converting all the traffic in the traffic set into test cases, these test cases can be used to form a test scenario that can test the target business scenario.

[0080] In this exemplary application: (1) The concept of a dyed environment is proposed. When a microservice is released, it can choose to release a dyed instance with a dyed identifier. Add a specific KEY with a value of the dyed identifier to the request header. In this way, when a request reaches a certain service, it will be preferentially forwarded to the dyed instance with the dyed identifier. After all microservices on which the business scenario depends release a dyed instance with the same dyed identifier, a complete and independent dyed environment can be obtained, which plays a role in environment isolation. (2) Use the means of traffic recording to generate API test cases and further combine them into test scenarios. Deploy an accompanying container Pod capable of recording traffic in each dyed instance through K8s to obtain all traffic reaching the corresponding dyed instance. Filter out all traffic based on the dyed identifier, that is, all operations in the dyed environment, convert the traffic into test cases, and then further filter these test cases according to business requirements. Finally, an expected test scenario is generated.

[0081] Embodiment 2 Figure 6 A block diagram of a test scenario generation device according to Embodiment 2 of the present application is schematically shown. The device can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiments of the present application. The program modules referred to in the embodiments of the present application refer to a series of computer program instruction segments that can complete specific functions. The following description will specifically introduce the functions of each program module in this embodiment. As Figure 6 shown, the device 1000 may include: a receiving module 1100, a forwarding module 1200, an obtaining module 1300, and a constructing module 1400, where: The receiving module 1100 is configured to receive a data request for a target business scenario, where the target business scenario is associated with one or more services, and the one or more services are pre-configured with dyed instances, and the dyed instances have dyed identifiers; The forwarding module 1200 is configured to determine a target data request based on the data request and forward the target data request to the dyed instances of the one or more services; where the target data request carries the dyed identifier; The obtaining module 1300 is configured to obtain the traffic of the dyed instances of the one or more services to obtain a traffic set; where the traffic is generated based on the target data request; The constructing module 1400 is configured to convert a plurality of test cases based on the traffic set, and the plurality of test cases are used to construct a test scenario for the target business scenario.

[0082] As an optional embodiment, receiving a data request for a target business scenario includes: Receive a data request associated with the one or more services, where the data request is from a target object; Based on the data request, determine the type of the target object, where the type includes: a test type, or a non-test type; In the case where the target object is of the test type, add the coloring identifier to the data request.

[0083] As an optional embodiment, the one or more services are further configured with a benchmark instance; correspondingly, determining a target data request based on the data request and forwarding the target data request to a coloring instance of the one or more services includes: Determine whether the data request carries the coloring identifier; In the case where the data request carries the coloring identifier, determine the data request as the target data request and forward the target data request to a coloring instance of the one or more services; In the case where the data request does not carry the coloring identifier, forward the data request to the benchmark instance of the one or more services.

[0084] As an optional embodiment, each coloring instance has an associated container, and the associated container is used to record the traffic of the corresponding coloring instance; Correspondingly, obtaining the traffic of the coloring instances of the one or more services to obtain a traffic set includes: Based on the associated container of each coloring instance, obtain the traffic of the coloring instances of the one or more services.

[0085] As an optional embodiment, the associated container is further used to: associatively store the traffic and the coloring identifier into a preset database; Correspondingly, obtaining the traffic of the coloring instances of the one or more services to obtain a traffic set includes: According to the coloring identifier, obtain the traffic of the coloring instances of the one or more services from the preset database.

[0086] As an optional embodiment, each service provides one or more interfaces; correspondingly, converting the traffic set into a plurality of test cases, where the plurality of test cases are used to construct a test scenario for the target business scenario, includes: Determine the corresponding service of each interface; Determine the traffic of the coloring instance of the corresponding service from the traffic set, and determine the preliminary screening traffic of each interface based on the traffic of the coloring instance of the corresponding service; Convert the preliminary screening traffic of each interface into a test case for the corresponding interface; According to the test cases of each interface, a test scenario for the target business scenario is formed.

[0087] As an optional embodiment, the traffic includes the target data request and the data response to the target data request, and the test case is obtained by converting based on the traffic.

[0088] Embodiment III Figure 7 Schematically shows a hardware architecture diagram of a computer device 10000 suitable for implementing the test scenario generation method according to Embodiment III of the present application. In some embodiments, the computer device 10000 may be a terminal device such as a smart phone, a wearable device, a tablet computer, a personal computer, a vehicle-mounted terminal, a game console, a virtual device, a workbench, a digital assistant, a set-top box, a robot, etc. In other embodiments, the computer device 10000 may be a rack server, a blade server, a tower server, or a cabinet server (including an independent server or a server cluster composed of multiple servers). As Figure 7 shown, the computer device 10000 includes, but is not limited to: a memory 10010, a processor 10020, and a network interface 10030 that can be communicatively linked to each other through a system bus. Among them: The memory 10010 includes at least one type of computer-readable storage medium. The readable storage medium includes flash memory, a hard disk, a multimedia card, a card-type memory (such as an SD or DX memory), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the memory 10010 may be an internal storage module of the computer device 10000, such as the hard disk or memory of the computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device 10000. Of course, the memory 10010 may also include both the internal storage module of the computer device 10000 and its external storage device. In this embodiment, the memory 10010 is generally used to store the operating system and various application software installed on the computer device 10000, such as the program code of the test scenario generation method. In addition, the memory 10010 may also be used to temporarily store various types of data that have been output or will be output.

[0089] The processor 10020 can be a Central Processing Unit (CPU), a controller, a microcontroller, a microprocessor, or other chips in some embodiments. The processor 10020 is generally used to control the overall operation of the computer device 10000, such as performing control and processing related to data interaction or communication with the computer device 10000. In this embodiment, the processor 10020 is used to run the program code stored in the memory 10010 or process data.

[0090] The network interface 10030 can include a wireless network interface or a wired network interface. The network interface 10030 is generally used to establish a communication link between the computer device 10000 and other computer devices. For example, the network interface 10030 is used to connect the computer device 10000 to an external terminal through a network, and establish a data transmission channel and a communication link between the computer device 10000 and the external terminal. The network can be an enterprise intranet (Intranet), the Internet, the Global System of Mobile communication (abbreviated as GSM), Wideband Code Division Multiple Access (abbreviated as WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi and other wireless or wired networks.

[0091] It should be noted that Figure 7 Only the computer device with components 10010 - 10030 is shown, but it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively.

[0092] In this embodiment, the test scenario generation method stored in the memory 10010 can also be divided into one or more program modules and executed by one or more processors (such as the processor 10020) to complete the embodiments of the present application.

[0093] Embodiment 4 The embodiments of the present application also provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the test scenario generation method in the embodiments are implemented.

[0094] In this embodiment, the computer-readable storage medium includes flash memory, hard disks, multimedia cards, card-type memories (e.g., SD or DX memories, etc.), random access memories (RAM), static random access memories (SRAM), read-only memories (ROM), electrically erasable programmable read-only memories (EEPROM), programmable read-only memories (PROM), magnetic memories, magnetic disks, optical disks, etc. In some embodiments, the computer-readable storage medium may be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc., equipped on the computer device. Of course, the computer-readable storage medium may also include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is generally used to store the operating system installed on the computer device and various application software, such as the program code of the test scenario generation method in the embodiment. In addition, the computer-readable storage medium may also be used to temporarily store various data that have been output or will be output.

[0095] Embodiment 5 The embodiment of the present application further provides a computer program product, including a computer program, which implements the method in the above embodiment when executed by a processor.

[0096] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the embodiments of the present application can be implemented by a general computer device. They can be concentrated on a single computer device or distributed on a network composed of multiple computer devices. Optionally, they can be implemented by program codes executable by the computer device. Thus, they can be stored in a storage device and executed by the computer device. And in some cases, the steps shown or described can be executed in a different order from here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module to implement. In this way, the embodiments of the present application are not limited to any specific combination of hardware and software.

[0097] It should be noted that the above are only the preferred embodiments of the present application, and do not limit the patent protection scope of the present application. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. A test scenario generation method, characterized in that: The method comprises: Receiving a data request for a target business scenario, the target business scenario is associated with one or more services, the one or more services are pre-configured with a dyeing instance, and the dyeing instance has a dyeing identifier; Determine a target data request based on the data request, and forward the target data request to the dyeing instance of the one or more services; wherein the target data request carries the dyeing identifier; Obtaining the traffic of the dyeing instances of the one or more services to obtain a traffic set; wherein the traffic is generated based on the target data request; A plurality of test cases are obtained based on the traffic set conversion, and the plurality of test cases are used to construct a test scenario for the target business scenario.

2. The method according to claim 1, characterized in that: Receive data requests for target business scenarios, including: receiving a data request associated with the one or more services, the data request coming from a target object; Based on the data request, determining the type of the target object, the type comprising: a test type or a non-test type; In the case where the target object is of the test type, the staining identifier is added to the data request.

3. The method according to claim 2, characterized in that The one or more services are also configured with a reference instance; correspondingly, determining a target data request based on the data request, and forwarding the target data request to the dyeing instance of the one or more services, including: Determining whether the data request carries the dyeing identifier; In a case where the data request carries the dyeing identifier, determining the data request as the target data request, and forwarding the target data request to the dyeing instances of the one or more services; When the data request does not carry the coloring identifier, the data request is forwarded to a reference instance of the one or more services.

4. The method according to claim 1, characterized in that Each dyeing instance has an associated container, and the associated container is used to record the traffic of the corresponding dyeing instance; Correspondingly, the traffic of the dyeing instances of the one or more services is obtained to obtain a traffic set, including: Based on the companion container of each of the dyeing instances, traffic of the dyeing instances of the one or more services is obtained.

5. The method according to claim 4, characterized in that The associated container is also used to: associate the flow rate with the dyeing mark and store it in a preset database; Correspondingly, the traffic of the dyeing instances of the one or more services is obtained to obtain a traffic set, including: According to the coloring identifier, traffic of the coloring instances of the one or more services is obtained from the preset database.

6. The method according to claim 1, characterized in that Each service provides one or more interfaces; correspondingly, multiple test cases are obtained based on the traffic set conversion, and the multiple test cases are used to construct a test scenario for the target business scenario, including: Determine the corresponding services for each interface; Determine the flow of the dyeing instance of the corresponding service from the flow set, and determine the initial screening flow of each interface based on the flow of the dyeing instance of the corresponding service; Convert the initial screening traffic of each interface into test cases of the corresponding interface; Based on the test cases of each interface, a test scenario for the target business scenario is composed.

7. The method according to any one of claims 1 to 6, characterized in that: The traffic includes the target data request and a data response to the target data request, and the test case is obtained based on the traffic conversion.

8. A test scenario generating device, characterized in that: The device comprises: A receiving module, configured to receive a data request of a target business scenario, wherein the target business scenario is associated with one or more services, wherein the one or more services are pre-configured with a dyeing instance, and the dyeing instance has a dyeing identifier; A forwarding module, configured to determine a target data request based on the data request, and forward the target data request to the dyeing instance of the one or more services; wherein the target data request carries the dyeing identifier; An acquisition module, used to acquire the traffic of the dyeing instances of the one or more services to obtain a traffic set; wherein the traffic is generated based on the target data request; A construction module is used to obtain multiple test cases based on the traffic set conversion, and the multiple test cases are used to construct a test scenario for the target business scenario.

9. A computer device, characterized in that: include: at least one processor; and a memory communicatively connected to the at least one processor; wherein: The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and when the computer instructions are executed by a processor, the method according to any one of claims 1 to 7 is implemented.

11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to claims 1 to 7 are implemented.

Images