Test case generation method and device, test case test method and device, medium and program product

Abstract

The invention discloses a test case generation method and device, a test case test method and device, a medium and a program product, and relates to the technical field of interface test and artificial intelligence, the method comprises the following steps: obtaining flow data of a first interface in a first service and a code corresponding to the first service; based on the traffic data, the code and a target model, a test case is generated, the test case comprises a test scene, test traffic and an assertion rule, and the test scene is used for representing a target field in the traffic data and a combination of values of the target field, the assertion rule is used for representing a target test result of the test case. According to the method, the generation efficiency of the test case can be improved under the condition of ensuring the test coverage and the code coverage.

Description

Technical Field

[0001] The present disclosure relates to the fields of interface testing technology, artificial intelligence technology, large model technology, and large language model technology, and specifically to the generation of test cases, testing methods, equipment, media, and program products. Background Art

[0002] Interface automation testing is an important way to ensure business quality in the software quality system. The corresponding use cases mainly include test execution logic, assertion methods, result measurement, etc. The generation of test cases generally involves writing the execution logic and assertion rules of the use cases. However, the more complex the business logic is, the lower the efficiency of the user's execution logic writing will be. At the same time, problems such as difficulty in preparing traffic data will also be encountered, which will lead to low efficiency in generating test cases. Summary of the invention

[0003] In view of this, the present disclosure provides a test case generation, a test method, a device, a medium and a program product to solve the problem of low test case generation efficiency.

[0004] In a first aspect, the present disclosure provides a method for generating a test case, the method comprising:

[0005] Obtaining traffic data of a first interface in a first service and a code corresponding to the first service;

[0006] Based on the traffic data, the code and the target model, a test case is generated, wherein the test case includes a test scenario, test traffic and assertion rules. The test scenario is used to characterize the target field in the traffic data and the combination of the values ​​of the target field. The assertion rule is used to characterize the target test result of the test case.

[0007] In a second aspect, the present disclosure provides a testing method, the method comprising:

[0008] Display the first configuration page;

[0009] In response to a configuration operation on a first service in the first configuration page and a first interface corresponding to the first service, first configuration information is obtained, the first configuration information is used to trigger the generation of a test case for the first interface, the test case is generated based on traffic data of the first interface, code corresponding to the first service, and a target model, the test case includes a test scenario, test traffic, and assertion rules, the test scenario is used to characterize a target field in the traffic data and a combination of values ​​of the target field, and the assertion rule is used to characterize a target test result of the test case;

[0010] The test case corresponding to the first interface in the first service is displayed on the test case interface.

[0011] In a third aspect, the present disclosure provides a test case generation device, the device comprising:

[0012] A data acquisition module, used to acquire traffic data of a first interface in a first service and a code corresponding to the first service;

[0013] A use case generation module is used to generate a test case based on the traffic data, the code and the target model. The test case includes a test scenario, test traffic and assertion rules. The test scenario is used to characterize the target field in the traffic data and the combination of the values ​​of the target field. The assertion rule is used to characterize the target test result of the test case.

[0014] In a fourth aspect, the present disclosure provides a testing device, the device comprising:

[0015] A first display module, used to display a first configuration page;

[0016] A first configuration module, configured to obtain first configuration information in response to a configuration operation on a first service in the first configuration page and a first interface corresponding to the first service, wherein the first configuration information is used to trigger generation of a test case for the first interface, wherein the test case is generated based on traffic data of the first interface, code corresponding to the first service, and a target model, wherein the test case includes a test scenario, test traffic, and assertion rules, wherein the test scenario is used to characterize a target field in the traffic data and a combination of values ​​of the target field, and the assertion rule is used to characterize a target test result of the test case;

[0017] A use case display module is used to display the test case corresponding to the first interface in the first service on the test case interface.

[0018] In a fifth aspect, the present disclosure provides an electronic device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, computer instructions are stored in the memory, and the processor executes the test case generation method of the above-mentioned first aspect or any corresponding embodiment thereof by executing the computer instructions, or executes the test method of the above-mentioned second aspect or any corresponding embodiment thereof.

[0019] In a sixth aspect, the present disclosure provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the test case generation method of the above-mentioned first aspect or any corresponding embodiment thereof, or to execute the test method of the above-mentioned second aspect or any corresponding embodiment thereof.

[0020] In a seventh aspect, the present disclosure provides a computer program product, comprising computer instructions, wherein the computer instructions are used to enable a computer to execute the method for generating test cases of the above-mentioned first aspect or any corresponding embodiment thereof, or to execute the test method of the above-mentioned second aspect or any corresponding embodiment thereof.

[0021] The method for generating a test case provided by the embodiment of the present disclosure obtains the flow data of the first interface in the first service and the code corresponding to the first service, and then generates a test case in combination with the target model, wherein the test case includes a test scenario, a test flow and an assertion rule, wherein the test scenario is used to characterize the target field in the flow data and the combination of the values ​​of the target field, and the assertion rule is used to characterize the target test result of the test case. The method introduces a target model to generate test cases, thereby avoiding the problem of manual writing. In addition, the generated test case includes a test scenario, a test flow and an assertion rule, and the test scope under the interface is described by the scenario. The setting of the test scenario can characterize which scenarios have generated test cases; the scenario is reversely covered by the test flow to ensure that all scenarios can be covered during the test, that is, the scenario is used to migrate the test coverage; in addition, the code of the first service is also combined when generating the test case to ensure code coverage. The method can improve the efficiency of test case generation while ensuring test coverage and code coverage.

[0022] The beneficial effects of the test method, the test case generating device, the test device, the electronic device, the storage medium and the program product correspond to the beneficial effects of the test case generating method and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the related technologies, the drawings required for use in the specific embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0024] Figure 1 is an optional schematic diagram of an application scenario according to an embodiment of the present disclosure;

[0025] Figure 2 is a flowchart of a method for generating a test case according to an embodiment of the present disclosure;

[0026] Figure 3 is a schematic diagram of the principle of generating a test case according to an embodiment of the present disclosure;

[0027] Figure 4is a flowchart of another test case generation method according to an embodiment of the present disclosure;

[0028] Figure 5 is another schematic diagram of the principle of generating a test case according to an embodiment of the present disclosure;

[0029] Figure 6 is a flowchart of another test case generation method according to an embodiment of the present disclosure;

[0030] Figure 7 is a schematic diagram of a page of an access platform according to an embodiment of the present disclosure;

[0031] Figure 8 is a schematic diagram of a service configuration page according to an embodiment of the present disclosure;

[0032] Fig. 9 is a page schematic diagram of an interface configuration according to an embodiment of the present disclosure;

[0033] Fig.10 is a schematic diagram of a page for configuring a test task according to an embodiment of the present disclosure;

[0034] Fig.11 is a schematic diagram of the testing principle according to an embodiment of the present disclosure;

[0035] Fig.12 is a schematic diagram of a test result page according to an embodiment of the present disclosure;

[0036] Fig.13 is a schematic diagram of a display page for detailed information of a test result according to an embodiment of the present disclosure;

[0037] Fig.14 is a schematic diagram of an assertion details page according to an embodiment of the present disclosure;

[0038] Fig.15 is a structural block diagram of a test case generation device according to an embodiment of the present disclosure;

[0039] Fig.16 is a structural block diagram of a testing device according to an embodiment of the present disclosure;

[0040] Fig.17 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present disclosure;

[0041] Fig.18 It is a schematic diagram of the hardware structure of another electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present disclosure.

[0043] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0044] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0045] As an optional but non-limiting implementation, in response to receiving an active request from the user, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0046] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet the relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0047] It is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0048] In the related art, a general traffic recording and playback platform is generally used to record traffic and play it back in a specific test lane, and then compare the difference playback results to identify problems. In this solution, the playback efficiency is low because the traffic recorded and played back is very large. In addition, there is a lot of noise in the difference assertions, such as timestamps, quantities, etc. There is also a lack of business scenarios in this solution. Since the traffic is recorded, played back, and managed according to the service and interface dimensions, it is difficult to accurately test according to the business scenario dimensions. In short, in the related art, the efficiency and quality of test case construction are low.

[0049] Among them, the construction quality of test cases in related technologies is low, which is mainly reflected in two aspects: insufficient automated testing and insufficient assertions. Specifically, test adequacy is an important indicator for measuring test integrity and ensuring quality. The basis for judging test adequacy mainly includes two categories: code coverage and business scenario coverage.

[0050] Code coverage: focuses on whether the code is executed during the test process, which can be subdivided into levels such as files, functions / interfaces, branches, and statements. Different quality standards will be defined according to the maturity of the business. However, since most business code coverage is still in the construction stage, it is difficult to achieve a high level of code coverage. Even with a high code coverage, it may not truly reflect the adequacy of the test. Code coverage does not mean that the actual business scenario is covered.

[0051] In some scenarios: Due to insufficient verification of automated test data, abnormal scenarios are not covered, although the code line coverage and problems are not recalled.

[0052] Scenario coverage: Evaluate the adequacy of the test from a business perspective. The essence of a test case is to describe the business scenario. By grading the case and evaluating the adequacy of the test plan execution and the pass rate, the adequacy of the test can be intuitively reflected. It is difficult to automate the description of business scenarios in the text case model. A test scenario description solution with engineering semantics is required, and the comprehensiveness and automation of the identification of the test scenario denominator must be ensured.

[0053] The accuracy and adequacy of assertions directly affect whether the test can actually find problems. There are two common assertion methods: logical assertions and difference assertions.

[0054] Diff assertion: The feature is that there is no need to maintain assertion rules, and the difference comparison is based on the test results and the original results. However, the core disadvantage is that Diff itself is prone to generate a lot of noise. Typical scenarios include: data inventory, timestamps, array disorder, etc., which require a lot of manpower costs for noise reduction processing.

[0055] Logical assertions: They have strong business logic and can judge problems more accurately through judgment logic. However, their core disadvantage is that logical assertions often require manual maintenance, and the accuracy, coverage, and maintenance efficiency of assertions are difficult to guarantee.

[0056] Furthermore, the low construction rate of test cases is mainly reflected in two aspects: high cost of test case production and high cost of test case maintenance.

[0057] Use case production cost: The more complex the business logic, the higher the cost of writing the execution logic of the use case. At the same time, there will be problems such as difficulty in data preparation. There will be as much automation as there is manual work. The writing of use case assertions requires a higher level of business understanding. If you want to write accurate and comprehensive assertions, the cost is extremely high.

[0058] Use case maintenance cost: With business iteration and personnel handover, the use case maintenance cost continues to increase, and may even become unmaintainable.

[0059] Based on this, the embodiment of the present disclosure provides a method for generating test cases, which automatically generates test cases. In this method, by combining the traffic data of the first interface in the first service and the code of the first service, the target model is used for analysis, and the test scenario, test traffic and assertion rules are automatically generated, and these three can form a test case. The concept of scenario is introduced in this method, and the test scope under this interface is described through the scenario. For example, taking the interface for publishing videos as an example, it may have 1,000 rules for publishing videos. Accordingly, these 1,000 rules need to be included in the test case. In order to characterize different rules, the concept of scenario is used to distinguish them in this method to ensure that all rules are covered.

[0060] The disclosed embodiment also provides a testing method, which undertakes the test behavior through test scenarios, test traffic and assertion rules. Whether the test passes is determined by whether the assertion passes, and whether the test is sufficient can be characterized by scenario coverage and code coverage, thereby completing the entire test.

[0061] Figure 1 It is an optional schematic diagram of an application scenario according to an embodiment of the present disclosure, and the entire test scenario includes a client 100 and a server 200. The test service and the test interface can be configured in the client 100, and accordingly, a test case including a test scenario, a test flow, and an assertion rule is generated in the server 200, and the test case corresponds to the test interface under the test service. In the test scenario, the client 100 determines the service to be tested and the corresponding interface, determines the corresponding test case by querying, etc., runs the test case according to the configured test lane in the server 200, generates the test result, and displays the test result on the client 100.

[0062] For the convenience of the following description, the terms involved are explained as follows:

[0063] Target field: Interface automated testing simulates test behavior through interface requests, verifies the input and output parameter information during the request process to determine whether the system is abnormal. There are some fields with strong business semantics in the input and output parameters of the interface. Different values ​​often represent different business scenarios, affecting the code coverage of the test. This type of field is defined as a target field and needs to be focused on during testing.

[0064] Test scenario: can be described as a series of feature combinations with business semantics, including target fields, combination methods, field values, etc. Test scenarios can accurately describe the real business scenarios and play a key role in driving and measuring the test.

[0065] Test denominator: All test scenarios that need to be tested for the current test requirements. For example, regression testing may involve all business test scenarios, while change testing only involves relevant test scenarios.

[0066] Test traffic: includes request and response content, which can be used for playback execution. Different test scenarios can be associated with different test traffic.

[0067] Assertion rules: A set of rules used to verify whether the test meets business expectations. Different test scenarios can be associated with different assertion rules.

[0068] Test case: It can also be called a scenario-based test case. The corresponding test traffic and assertion rules are associated through the test scenario, that is, a scenario-based test case is formed.

[0069] According to an embodiment of the present disclosure, an embodiment of a method for generating a test case is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0070] In this embodiment, a method for generating a test case is provided, which can be used for the above-mentioned electronic device, such as a server, etc. Figure 2 is a flow chart of a method for generating a test case according to an embodiment of the present disclosure, such as Figure 2 As shown, the process includes the following steps:

[0071] Step S201, obtaining traffic data of a first interface in a first service and a code corresponding to the first service.

[0072] In the field of interface testing, the interface of a service is tested. The interface here refers to the interface that is normally called, that is, the client or the front end of the client calls the service interface, thereby calling the server's capabilities to perform some logical processing. Accordingly, the first interface in the first service can be the client calling the server interface, or the client's front end calling the server interface.

[0073] The first interface in the first service is used to indicate that the generated test case corresponds to the interface. The flow data of the first interface can be flow data of requesting the first interface, or can be response flow data of the first interface in response to the request.

[0074] The code corresponding to the first service may be obtained from a code repository of the first service, in which the definition of the first interface, or some fields of the first service and the meanings of the fields, etc., may be defined. The target model is then used to analyze the code to mine test scenarios, etc.

[0075] Step S202, generating test cases based on traffic data, code and target model.

[0076] The test case includes a test scenario, test traffic, and assertion rules. The test scenario is used to characterize the target field in the traffic data and the combination of the target field values. The assertion rule is used to characterize the target test result of the test case.

[0077] The input of the target model includes traffic data and code, and the output includes test scenarios, test traffic, and assertion rules. The target model performs data mining based on the input content and outputs the corresponding content.

[0078] A test scenario represents a combination of target fields and their values ​​in traffic data. As described above, the concept of scenario is introduced to define the test scope of the corresponding interface. Therefore, by defining the test scenario, test cases have been generated to represent the scope of the interface to ensure scenario coverage.

[0079] Assertion rules include whether the corresponding fields in the interface traffic data meet expectations and whether the values ​​of the fields meet expectations. For example, calling an interface may return 10 fields, and you need to use assertion rules to determine whether some of the 10 fields meet expectations. This process involves two dimensions: one is which fields need to be asserted, and the other is the assertion of field values. For example, if a status code = 200 is returned, and the expected status code is code = 400, then the assertion fails because the status code value does not meet expectations.

[0080] Figure 3This is a schematic diagram of the principle of generating test cases according to the embodiment of the present disclosure. The test scenario is obtained by combining the target field and the target field value; the test scenario, test traffic and assertion rules form a test case. For subsequent test tasks, the test service, test scenario, execution traffic and assertion rules are tested to obtain the corresponding test results.

[0081] like Figure 3 As shown in the figure, the same target field in the test scenario can form different test scenarios under different value conditions. The same test scenario can correspond to multiple test flows and assertion rules, and the same test task can be tested by multiple test cases. It should be noted that Figure 3 The values ​​of m and n are determined according to actual conditions and are not limited here.

[0082] The test case generation method provided in this embodiment introduces a target model to generate test cases, avoiding the problem of manual writing. In addition, the generated test cases include test scenarios, test traffic, and assertion rules. The test scope under the interface is described through the scenario. The setting of the test scenario can characterize which scenarios have generated test cases; the scenario is reversely covered by the test traffic to ensure that all scenarios can be covered during the test, that is, the scenario is used to migrate the test coverage; in addition, when generating test cases, the code of the first service is also combined to ensure code coverage. This method can improve the efficiency of test case generation while ensuring test coverage and code coverage.

[0083] In this embodiment, a method for generating a test case is provided, which can be used for the above-mentioned electronic device, such as a server, etc. Figure 4 is a flow chart of a method for generating a test case according to an embodiment of the present disclosure, such as Figure 4 As shown, the process includes the following steps:

[0084] Step S401, obtain the traffic data of the first interface in the first service and the code corresponding to the first service. Figure 2 Step S201 of the illustrated embodiment will not be described in detail here.

[0085] Step S402, generating test cases based on traffic data, code and target model.

[0086] The test case includes a test scenario, test traffic, and assertion rules. The test scenario is used to characterize the target field in the traffic data and the combination of the target field values. The assertion rule is used to characterize the target test result of the test case.

[0087] Specifically, the above step S402 includes:

[0088] Step S4021, compress the flow data to obtain target flow data.

[0089] Since the traffic data is for the same interface, similar or related traffic data may exist in the traffic data of the first interface. For similar traffic data, only one or two of them can be retained, and the rest can be ignored to reduce the data processing amount of the target model. Based on this, the traffic data of the first interface can be compressed to obtain the target traffic data for input into the target model.

[0090] In some optional implementations, the above step S4021 includes:

[0091] Step a1, obtaining multiple flow data in the current detection cycle.

[0092] Step a2: determining similar traffic data and preset traffic data based on the characteristics of the traffic data.

[0093] Step a3: based on similar traffic data and preset traffic data, multiple traffic data are screened to obtain target traffic data.

[0094] The target model processes data based on the detection cycle. In the current detection cycle, multiple flow data can be obtained for the first interface, and feature analysis is performed on these flow data to determine similar flow data and preset flow data. Among them, the specified fields of the flow data and their values ​​can be extracted, and similar features are calculated based on the extraction results, and flow data with a similarity higher than a preset similarity can be determined as similar flow data.

[0095] The preset traffic data is used to characterize the traffic data that needs to be retained, that is, the core traffic data of the first interface. These traffic data can often be characterized by preset fields, that is, by identifying the fields in the traffic data, the traffic data including the preset fields can be determined as the preset traffic data.

[0096] Similar flow data can only retain one or two of them according to actual needs. The preset flow data is the flow data that needs to be retained. Based on this, multiple flow data in the current detection cycle can be marked to distinguish which ones need to be retained and which ones need to be filtered out. Filter each flow data according to its identification to obtain the target flow data.

[0097] After obtaining the original traffic data in the first interface, explore the variation (i.e., traffic data compression) thereof, including analyzing which traffic data are similar and which traffic data are core, and compressing them to obtain the target traffic data. For example, if 10,000 traffic data are obtained in the current detection cycle, only 100 target traffic data may be retained after traffic data compression.

[0098] For multiple flow data in the current detection cycle, since there may be similar flow data, only one piece of similar flow data can be retained; there may also be preset flow data (i.e., core flow data), and these preset flow data need to be retained to ensure accuracy. Therefore, by screening the flow data, the amount of flow data can be reduced while ensuring accuracy.

[0099] Step S4022, perform semantic analysis on the code to obtain a semantic analysis result.

[0100] As described above, the code of the first service comes from the code repository of the first service. The code in the code repository is analyzed for code semantics. For example, the meaning of a specified field in the first service, the relationship between the fields, etc. are identified to obtain a semantic analysis result.

[0101] The semantic analysis may be implemented through a language model, through field recognition, etc., and no limitation is imposed on the analysis method.

[0102] Step S4023, using the target model to process the target traffic data and the semantic analysis results to obtain the test scenario, test traffic and assertion rules.

[0103] The target traffic data and semantic analysis results obtained after the above steps S4021 and S4022 are input into the target model for processing to obtain the test scenario, test traffic and assertion rules. The input of the target model may also include prompt information for instructing the target model to mine the corresponding data.

[0104] Step S4024, associate the test scenario, test traffic and assertion rules to obtain a test case.

[0105] The output of the target model includes a test scenario, a test flow, and an assertion rule, and these three are associated to obtain a test case corresponding to the first interface.

[0106] For example, Figure 5This is another schematic diagram of the principle of generating a test case according to an embodiment of the present disclosure. Specifically, the original traffic data obtained from the first interface is compressed to obtain the target traffic data, the code in the code repository of the first service is semantically analyzed to obtain the semantic analysis result, and the target traffic data and the semantic analysis result are input into the target model to obtain the test scenario, test traffic and assertion rules. These three are associated to generate a test case corresponding to the first interface.

[0107] Furthermore, for the generated test cases, the test graph can be characterized. That is, the graph is characterized and used as an output asset, which is then output to the client for consumption. In addition, the characterized graph can be dynamically preserved. Dynamic preservation refers to the original traffic data and code parameters, which will change. By detecting this change, the reverse cycle is continuously carried out. Figure 5 The process shown achieves dynamic freshness preservation.

[0108] The test case generation method provided in this embodiment reduces the data processing amount of the target model by compressing the traffic data; performs semantic analysis on the code and then processes it in combination with the target model, thereby improving the processing accuracy of the target model, that is, it is possible to improve the test case generation efficiency while ensuring the accuracy of the test case.

[0109] In some optional implementations, the above test case generation method further includes:

[0110] Step b1, detecting changes in flow data and codes of the first interface.

[0111] Step b2: If the traffic data and / or code of the first interface changes, the generated test case is updated based on the changed traffic data and / or code using the target model to obtain an updated test case.

[0112] As described above, the traffic data and code parameters of the first interface may be variable. Based on this, by detecting the corresponding changes, if it is detected that the traffic data and / or code have changed, the target model is triggered to update the generated test cases according to the changed traffic data and / or code to obtain updated test cases. This process is the dynamic preservation described above.

[0113] In some optional implementations, the generated test cases can be displayed on the client and manually confirmed. If the user feels that it is inaccurate after analysis, manual intervention will be given priority, and the data modified by manual interaction will be used as the final test case.

[0114] By detecting traffic data and code changes, the generated test cases are updated in a timely manner to ensure the accuracy of the test cases.

[0115] In some optional implementations, the above test case generation method further includes:

[0116] Step c1, obtaining the first configuration information of the service for which a test case needs to be generated and the interface corresponding to the service.

[0117] Step c2: determine the first service and the first interface in the first service based on the first configuration information.

[0118] Before generating a test case, it is necessary to determine which service and interface to generate the test case for. The service and interface can be configured on the client and then synchronized to the server. Accordingly, the server can obtain the first configuration information of the service and the corresponding interface for which the test case needs to be generated.

[0119] Alternatively, the services and corresponding interfaces may also be determined in a pre-made order, etc. Of course, other methods may also be used to obtain the first configuration information. The specific configuration is based on actual needs and is not limited here.

[0120] After obtaining the first configuration information, the first configuration information may be subjected to field analysis to determine the first service and the first interface in the first service. Of course, other methods may be used to determine the first service and the first interface in the first service from the first configuration information. The first service and the first interface are determined based on the first configuration information, and test cases are generated as needed.

[0121] In some optional implementations, the above test case generation method further includes:

[0122] Step d1, obtaining second configuration information of the test task, where the second configuration information includes a test service and a test interface of the test service.

[0123] Step d2, determining the test case corresponding to the test interface of the test service.

[0124] Step d3, testing the test interface of the test service based on the determined test case to obtain the test result.

[0125] After the test case is generated, the interface of the corresponding service can be tested according to the test case to obtain the test result. That is, the second configuration information is obtained by configuring the test task, and accordingly, the test is performed in the server according to the second configuration information.

[0126] The second configuration information includes the test service and the test interface of the test service. According to the test interface of the test service, a query can be made in the test case set to determine the test case corresponding to the test interface of the test service. After the test case is determined, the test interface of the test service can be tested based on the test case to obtain the test result. The test result can be fed back to the client and displayed on the client so that the test result can be intuitively understood.

[0127] The test task is determined according to the second configuration information, and the corresponding test case is obtained to test the test interface to obtain accurate test results.

[0128] It should be noted that the determination of the test case in the above step d2 is related to the type of test task. The type of test task can be regression testing or change testing. Among them, regression testing can refer to testing for existing requirements, and change testing can refer to testing for changes to existing requirements or new requirements. Since it is a change to an existing requirement or a new requirement, there may be no corresponding test case in the test case set. Therefore, in this solution, the generation of the corresponding test case is first triggered for the change to the existing requirement or the new requirement, and then the test is performed to obtain the test result.

[0129] In some optional implementations, the above step d2 includes:

[0130] Step d21: if the test task is a regression test for an existing requirement, query the test case set according to the test interface of the test service to determine the test case corresponding to the test interface of the test service.

[0131] Step d22: If the test task is a test for a change requirement, code change information corresponding to the change requirement in the code of the test service is obtained.

[0132] Step d23, generating change test cases based on the code change information and the target model.

[0133] Step d24, querying the test case set according to the test interface of the test service, determining the existing test cases corresponding to the test interface of the test service, the test cases corresponding to the test interface include changed test cases and existing test cases.

[0134] The type of the test task can be marked when creating the test task, or it can be determined after analyzing the test interface of the test service. If the test interface of the test service has not previously generated a corresponding test case, it can be determined that it is a change test, etc.

[0135] If it is determined that the test task is a regression test for an existing requirement, the test case set can be queried based on the test interface of the test service to determine the test case corresponding to the test interface of the test service.

[0136] If it is determined that the test task is a test for a change requirement, the code change information corresponding to the change requirement in the code of the test service is obtained. The target model is then triggered to generate a change test case based on the code change information, and then the test case for the change test is determined in combination with the existing test cases queried.

[0137] For testing of change requirements, we first generate change test cases based on the code change information, and then process the test tasks in combination with existing test cases. We provide different test solutions for different test phases, especially for the change test phase, providing a precise test mode.

[0138] For example, Fig.11 As shown in the figure, the test cases generated according to the target model include test scenarios, test traffic, and assertion rules. During the test process, the corresponding test cases are first determined according to the type of test task. For regression testing, service information (including the service to be tested and the interface corresponding to the service) is obtained, and a query can be made in the test data set to obtain a full set of test cases, and then the test task is executed according to the full set of test cases to obtain the test results and generate a test report.

[0139] For change testing, obtain code change information, analyze the changed code to generate change test cases, execute the test tasks, obtain the test results and generate a test report. For change testing of change requirements, this solution will add a capability based on the above test process, because the existing test case set may not be complete, and the new changes may have some new code, and the corresponding test cases have not been generated in time. Based on this, by providing an incremental capability, change test cases can be automatically generated based on the submitted change information. Specifically, by identifying the corresponding changed code, combined with the capabilities of the target model, a test case that can cover the changed code can be quickly generated. The traffic corresponding to this part of the code may not have existed originally, and it is a process generated from 0, but this can be achieved end-to-end, and then it can not only achieve the impact of the existing code change, but also the incremental new code generated from 0 can also achieve rapid coverage. It should be noted that the process of generating test reports is the same, but an additional capability is added, that is, in the change test phase, the changed part of the code can also quickly generate a change case and test it.

[0140] In some optional embodiments, the above-mentioned test case generation method also includes: if the test scenario coverage and / or code coverage represented in the test results do not meet the corresponding preset conditions, the parameters of the target model are adjusted to obtain an updated target model.

[0141] Specifically, the test cases generated by the target model may have test scenario coverage and / or code coverage that do not meet the corresponding preset conditions. In this case, it is necessary to fine-tune the parameters of the target model. That is, the target model can adjust its parameters accordingly based on the actual test results.

[0142] When it is determined that the corresponding preset conditions are not met, the parameters of the target model are automatically adjusted to achieve continuous iterative optimization of the target model in order to obtain more accurate test cases.

[0143] According to an embodiment of the present disclosure, a testing method embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0144] In this embodiment, a testing method is provided, which can be used for the above-mentioned electronic devices, such as clients, etc. Figure 6 is a flow chart of a method for generating a test case according to an embodiment of the present disclosure, such as Figure 6 As shown, the process includes the following steps:

[0145] Step S601: display a first configuration page.

[0146] The first configuration page is used to guide users to configure services and corresponding interfaces, and displays fields and field values ​​that need to be configured on the first configuration page. The field values ​​can be configured in the form of a list for selection or in the form of a text box for interactive input.

[0147] Step S602: In response to a configuration operation on a first service in a first configuration page and a first interface corresponding to the first service, first configuration information is obtained.

[0148] Among them, the first configuration information is used to trigger the generation of test cases for the first interface. The test cases are generated based on the traffic data of the first interface, the code corresponding to the first service, and the target model. The test cases include test scenarios, test traffic, and assertion rules. The test scenarios are used to characterize the target fields in the traffic data and the combination of the values ​​of the target fields. The assertion rules are used to characterize the target test results of the test cases.

[0149] For example, Figure 7 is a schematic diagram of a page of an access platform according to an embodiment of the present disclosure. If you need to add a new service, you can interact with the new service control to enter Figure 8 The page shown. Figure 8 Configure the added service. During the configuration process, you need to specify the values ​​of service field 1 to service field 3.

[0150] After the service configuration is completed, you need to configure the interface corresponding to the service. For example, you can enter Fig. 9 Configure the interface on the page shown.

[0151] It should be noted that the fields to be configured for services and fields are not limited to Figure 8 Service fields 1 to 3 in Fig. 9 The interface fields 1 to 3 shown in the figure may also include other service fields and other interface fields, which are not limited here and can be set according to actual needs.

[0152] After performing interactive operations with each page, configuration information of the first service and the first interface of the first service is obtained, that is, first configuration information is obtained.

[0153] In addition, for the specific application of the first configuration information, please refer to the description of the test case generation method above, which will not be repeated here.

[0154] Step S603: Display the test case corresponding to the first interface in the first service on the test case interface.

[0155] As described above, after obtaining the first configuration information, the target model in the server can be triggered to generate a test case. Accordingly, the test case corresponding to the first interface in the first service can be displayed on the test case interface.

[0156] In some optional implementations, the generated test cases may be modified in an interactive manner to obtain modified test cases, and the test cases stored in the server may be synchronously updated.

[0157] The test method provided in this embodiment configures the first service and the first interface on the first configuration page of the client to trigger the generation of test cases for the first interface of the first service; the generated test cases are displayed on the test case interface to adjust them and improve the accuracy of the test cases.

[0158] In some optional embodiments, the above-mentioned testing method further includes:

[0159] Step e1, displaying the second configuration page.

[0160] Step e2, in response to the configuration operation on the test service in the second configuration page and the test interface corresponding to the test service, obtain second configuration information, the second configuration information is used to trigger the test on the test interface.

[0161] Step e3: Display the test results of the test interface on the test result page.

[0162] The test case is used to complete the test task. Accordingly, the test service and the test interface corresponding to the test service need to be configured in the test task. Based on this, the second configuration page is used to guide the user to configure the test service and the test interface.

[0163] For example, Fig.10 As shown, the configuration of the test task may involve the configuration of task fields 1 to 3, and the values ​​of the corresponding fields are configured in an interactive manner to obtain the second configuration information.

[0164] After the test task configuration is completed, the server is triggered to execute the test task based on the test case set to obtain the test result. Accordingly, the test result is fed back to the client, so that the test result is displayed on the test result page of the client.

[0165] The test task is configured on the second test page of the client to trigger the test for the test interface, and the corresponding test results are displayed on the test result page to achieve intuitive display of the test results for timely error correction.

[0166] In some optional implementations, the test result page includes a first tab and a second tab. The first tab is used to trigger the display of statistical information of the test result, and the second tab is used to trigger the display of detailed information of the test result.

[0167] On the test result page, different tabs can be used to switch the display of different forms of test results. Specifically, the first tab is used to trigger the display of statistical information of the test results, where the statistical scope includes but is not limited to the number of successfully executed test cases, execution success rate, assertion pass rate, scenario coverage, code coverage, etc. For example, Fig.12 As shown, the first tab is selected interactively, and accordingly, statistical information of the test results is displayed.

[0168] like Fig.13 As shown, the second tab is used to trigger the display of detailed information of the test results, including but not limited to the list of executed test cases, the execution results of each test case, and assertion details, etc. Different information is distinguished by different tabs so as to be displayed as needed.

[0169] In some optional embodiments, the above-mentioned testing method further includes: in response to a selection operation of the assertion details corresponding to the test case in the detailed information, displaying an assertion details page, the assertion details page including the test results of the assertion rules associated with the test case, and the traffic data corresponding to the test case.

[0170] By interacting with the Assertion Details control, the Assertion Details page is displayed. For example, Fig.14 As shown, the assertion details page includes the test results of the assertion rules associated with the test case and the traffic data of the test case. As described above, the assertion details correspond to the test case. When entering the assertion details page, the assertion rules corresponding to the test case can be displayed. For example, Fig.14 Assertion rules 1 to 3 are shown in FIG. Accordingly, corresponding traffic data can be displayed for each assertion rule, for example, Fig.14 The request traffic and the corresponding response traffic shown in .

[0171] Furthermore, if the assertion result of the corresponding assertion rule is not passed, then the reason why the assertion rule is not passed can be displayed at the corresponding position of the request flow or the corresponding response flow; or the flow data that is not passed can be marked in the flow data, etc. It can be set according to actual needs, and there is no limitation on it here.

[0172] After selecting the assertion details, the assertion details information page is displayed, which shows the test results and traffic data, so that you can intuitively understand the reasons why the test failed.

[0173] As a specific application embodiment of the embodiment of the present disclosure, a platform access application is deployed in the client, and the first configuration information is set by interacting with the platform access application. The first configuration information is synchronized to the server, and the above-mentioned test case generation method is executed in the server to form a test case set corresponding to the first interface in the first service. When testing is required, the test task is configured in the platform access application in the client to obtain the second configuration information. The server tests the test interface in the test service based on the second configuration information, obtains the test results and forms a test report. The test report is synchronized to the client, so that the test report is displayed in the client.

[0174] This method associates entities such as test traffic and assertion rules through test scenarios, defines the denominator of the entire automated test through scenarios, associates the rule content that needs to be asserted through scenarios, and measures the adequacy of the test through scenario coverage. In addition, based on the capabilities of the target model, this method automatically mines and dynamically preserves test cases around indicators such as scenario coverage and code coverage.

[0175] During the test process, different test solutions are provided for different test types. Especially in the change test phase, complete test results are obtained by providing accurate test modes. The adequacy of the test is ensured through scenario coverage, and the efficiency of the test is ensured through accurate testing and traffic compression.

[0176] In this embodiment, a test case generation device and a test device are also provided, which are used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0177] This embodiment provides a test case generation device, such as Fig.15 As shown, including:

[0178] The data acquisition module 1501 is used to acquire the traffic data of the first interface in the first service and the code corresponding to the first service.

[0179] The use case generation module 1502 is used to generate test cases based on traffic data, code and target model. The test cases include test scenarios, test traffic and assertion rules. The test scenarios are used to characterize the target fields in the traffic data and the combination of target field values. The assertion rules are used to characterize the target test results of the test cases.

[0180] In some optional implementations, the use case generation module 1502 includes:

[0181] The compression unit is used to compress the flow data to obtain target flow data.

[0182] The semantic analysis unit is used to perform semantic analysis on the code and obtain semantic analysis results.

[0183] The model processing unit is used to process the target traffic data and semantic analysis results using the target model to obtain the test scenario, test traffic and assertion rules.

[0184] The association unit is used to associate the test scenario, test traffic and assertion rules to obtain the test case.

[0185] In some optional embodiments, the compression unit comprises:

[0186] The flow data acquisition subunit is used to acquire multiple flow data in the current detection cycle.

[0187] The flow data determination subunit is used to determine similar flow data and preset flow data based on the characteristics of the flow data.

[0188] The flow data screening subunit is used to screen multiple flow data based on similar flow data and preset flow data to obtain target flow data.

[0189] In some optional implementations, the test case generating device further includes:

[0190] The detection module is used to detect the flow data of the first interface and the change of the code.

[0191] The update module is used to update the generated test cases based on the changed traffic data and / or code by using the target model to obtain updated test cases if the traffic data and / or code of the first interface changes.

[0192] In some optional implementations, the test case generating device further includes:

[0193] The first configuration acquisition module is used to acquire first configuration information of the service for which a test case needs to be generated and the interface corresponding to the service.

[0194] The interface determination module is used to determine the first service and the first interface in the first service based on the first configuration information.

[0195] In some optional implementations, the test case generating device further includes:

[0196] The second configuration acquisition module is used to acquire second configuration information of the test task, where the second configuration information includes a test service and a test interface of the test service.

[0197] The use case determination module is used to determine the test case corresponding to the test interface of the test service.

[0198] The interface testing module is used to test the test interface of the test service based on the determined test cases to obtain the test results.

[0199] In some optional implementations, the use case determination module includes:

[0200] The first query unit is used to query the test case set according to the test interface of the test service if the test task is a regression test for an existing requirement, and determine the test case corresponding to the test interface of the test service.

[0201] In some optional implementations, the use case determination module includes:

[0202] The code change unit is used to obtain code change information corresponding to the change requirement in the code of the test service if the test task is a test for the change requirement.

[0203] The change case generation unit is used to generate change test cases based on code change information and target models.

[0204] The second query unit is used to query the test case set according to the test interface of the test service, and determine the existing test cases corresponding to the test interface of the test service. The test cases corresponding to the test interface include changed test cases and existing test cases.

[0205] In some optional implementations, the test case generating device further includes:

[0206] The parameter adjustment module is used to adjust the parameters of the target model to obtain an updated target model if the test scenario coverage and / or code coverage represented in the test results do not meet the corresponding preset conditions.

[0207] This embodiment provides a testing device, such as Fig.16 As shown, including:

[0208] The first display module 1601 is used to display a first configuration page.

[0209] The first configuration module 1602 is used to obtain first configuration information in response to configuration operations on the first service in the first configuration page and the first interface corresponding to the first service. The first configuration information is used to trigger the generation of a test case for the first interface. The test case is generated based on the traffic data of the first interface, the code corresponding to the first service, and the target model. The test case includes a test scenario, test traffic, and assertion rules. The test scenario is used to characterize the target field in the traffic data and the combination of the target field values. The assertion rule is used to characterize the target test result of the test case.

[0210] The use case display module 1603 is used to display the test case corresponding to the first interface in the first service on the test case interface.

[0211] In some optional embodiments, the testing device further comprises:

[0212] The second display module is used to display the second configuration page.

[0213] The first response module is used to obtain second configuration information in response to the configuration operation on the test service in the second configuration page and the test interface corresponding to the test service, and the second configuration information is used to trigger the test on the test interface.

[0214] The result display module is used to display the test results of the test interface on the test result page.

[0215] In some optional implementations, the test result page includes a first tab and a second tab, the first tab is used to trigger the display of statistical information of the test results, and the second tab is used to trigger the display of detailed information of the test results.

[0216] In some optional embodiments, the testing device further comprises:

[0217] The second response module is used to respond to the selection operation of the assertion details corresponding to the test case in the detailed information, and display the assertion details page, which includes the test results of the assertion rules associated with the test case and the traffic data corresponding to the test case.

[0218] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0219] The test case generation device and the test device in this embodiment are presented in the form of functional units, where the units may refer to ASIC (Application Specific Integrated Circuit) circuits, processors and memories that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0220] The present disclosure also provides an electronic device having the above Fig.15 The test case generator shown, or Fig.16 The test setup is shown.

[0221] See also Fig.17 or Fig.18 , Fig.17 or Fig.18 It is a structural schematic diagram of an electronic device provided by an optional embodiment of the present disclosure. Fig.17 FIG. 1 is a schematic diagram of the structure of an electronic device for executing the test case generation method provided in an embodiment of the present disclosure. Fig.18 FIG. 1 is a schematic diagram of the structure of an electronic device for executing the test method provided in the embodiment of the present disclosure. Fig.17 or Fig.18As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig.17 or Fig.18 A processor 10 is taken as an example.

[0222] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0223] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0224] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0225] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0226] like Fig.17 As shown, the electronic device further includes a communication interface 50 for the electronic device to communicate with other devices or a communication network.

[0227] like Fig.18 As shown, the electronic device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Fig.18 The example of connecting through bus is taken in the following.

[0228] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the electronic device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator rod, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED) and a tactile feedback device (e.g., a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can be a touch screen.

[0229] The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium and downloaded through a network, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0230] A part of the present disclosure may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present disclosure through the operation of the computer. Those skilled in the art should understand that the existence of computer program instructions in computer-readable media includes, but is not limited to, source files, executable files, installation package files, etc., and accordingly, the way in which computer program instructions are executed by a computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.

[0231] Although the embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for generating a test case, characterized in that: The method comprises: Obtaining traffic data of a first interface in a first service and a code corresponding to the first service; Based on the traffic data, the code and the target model, a test case is generated, wherein the test case includes a test scenario, test traffic and assertion rules. The test scenario is used to characterize the target field in the traffic data and the combination of the values ​​of the target field. The assertion rule is used to characterize the target test result of the test case.

2. The method according to claim 1, characterized in that The generating of test cases based on the traffic data, the code and the target model includes: compressing the flow data to obtain target flow data; Performing semantic analysis on the code to obtain a semantic analysis result; Processing the target traffic data and the semantic analysis result using the target model to obtain the test scenario, the test traffic, and the assertion rule; The test scenario, the test traffic, and the assertion rule are associated to obtain the test case.

3. The method according to claim 2, characterized in that The compressing the flow data to obtain target flow data includes: Get multiple flow data in the current detection cycle; Based on the characteristics of the flow data, determining similar flow data and preset flow data; Based on similar traffic data and the preset traffic data, the plurality of traffic data are screened to obtain the target traffic data.

4. The method according to claim 1, characterized in that: The method further comprises: Detecting the flow data of the first interface and the change of the code; If the traffic data and / or the code of the first interface changes, the generated test case is updated based on the changed traffic data and / or the code using the target model to obtain an updated test case.

5. The method according to claim 1, characterized in that The method further comprises: Obtaining first configuration information of a service for which a test case needs to be generated and an interface corresponding to the service; The first service and a first interface in the first service are determined based on the first configuration information.

6. The method according to claim 1, characterized in that The method further comprises: Acquire second configuration information of the test task, where the second configuration information includes a test service and a test interface of the test service; Determine the test case corresponding to the test interface of the test service; The test interface of the test service is tested based on the determined test case to obtain a test result.

7. The method according to claim 6, characterized in that The determining of the test case corresponding to the test interface of the test service includes: If the test task is a regression test for an existing requirement, a test case set is queried according to the test interface of the test service to determine the test case corresponding to the test interface of the test service.

8. The method according to claim 6, characterized in that The determining of the test case corresponding to the test interface of the test service includes: If the test task is a test for a change requirement, obtaining code change information corresponding to the change requirement in the code of the test service; Generate a change test case based on the code change information and the target model; A test case set is queried according to the test interface of the test service to determine an existing test case corresponding to the test interface of the test service, wherein the test case corresponding to the test interface includes the changed test case and the existing test case.

9. The method according to claim 6, characterized in that The method further comprises: If the test scenario coverage and / or code coverage represented in the test results do not meet the corresponding preset conditions, the parameters of the target model are adjusted to obtain an updated target model.

10. A testing method, characterized in that: The method comprises: Display the first configuration page; In response to a configuration operation on a first service in the first configuration page and a first interface corresponding to the first service, first configuration information is obtained, the first configuration information is used to trigger the generation of a test case for the first interface, the test case is generated based on traffic data of the first interface, code corresponding to the first service, and a target model, the test case includes a test scenario, test traffic, and assertion rules, the test scenario is used to characterize a target field in the traffic data and a combination of values ​​of the target field, and the assertion rule is used to characterize a target test result of the test case; The test case corresponding to the first interface in the first service is displayed on the test case interface.

11. The method according to claim 10, characterized in that The method further comprises: Display the second configuration page; In response to a configuration operation on the test service in the second configuration page and a test interface corresponding to the test service, second configuration information is obtained, where the second configuration information is used to trigger a test on the test interface; The test results of the test interface are displayed on the test result page.

12. The method according to claim 11, characterized in that The test result page includes a first tab and a second tab, the first tab is used to trigger the display of statistical information of the test result, and the second tab is used to trigger the display of detailed information of the test result.

13. The method according to claim 12, characterized in that The method further comprises: In response to a selection operation of the assertion details corresponding to the test case in the detailed information, an assertion details page is displayed, the assertion details page including the test results of the assertion rules associated with the test case and the traffic data corresponding to the test case.

14. A test case generation device, characterized in that: The device comprises: A data acquisition module, used to acquire traffic data of a first interface in a first service and a code corresponding to the first service; A use case generation module is used to generate a test case based on the traffic data, the code and the target model. The test case includes a test scenario, test traffic and assertion rules. The test scenario is used to characterize the target field in the traffic data and the combination of the values ​​of the target field. The assertion rule is used to characterize the target test result of the test case.

15. A testing device, characterized in that: The device comprises: A first display module, used to display a first configuration page; A first configuration module, configured to obtain first configuration information in response to a configuration operation on a first service in the first configuration page and a first interface corresponding to the first service, wherein the first configuration information is used to trigger generation of a test case for the first interface, wherein the test case is generated based on traffic data of the first interface, code corresponding to the first service, and a target model, wherein the test case includes a test scenario, test traffic, and assertion rules, wherein the test scenario is used to characterize a target field in the traffic data and a combination of values ​​of the target field, and the assertion rule is used to characterize a target test result of the test case; A use case display module is used to display the test case corresponding to the first interface in the first service on the test case interface.

16. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the test case generation method described in any one of claims 1 to 9, or executes the test method described in any one of claims 10 to 13 by executing the computer instructions.

17. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the test case generation method described in any one of claims 1 to 9, or to execute the test method described in any one of claims 10 to 13.

18. A computer program product, characterized in that The invention comprises computer instructions, wherein the computer instructions are used to make a computer execute the test case generation method according to any one of claims 1 to 9, or execute the test method according to any one of claims 10 to 13.

Images