Test method, apparatus, device, and storage medium

Abstract

This application provides a testing method, apparatus, device, and storage medium, relating to the field of computer technology. The method involves: responding to a test execution request triggered by a target object, obtaining a list of test cases; performing the following operations for each test case in the list: initiating an interface request to a preview machine based on the interface request data corresponding to a test case, obtaining the execution result corresponding to a test case, verifying the execution result, and determining the test result of a test case; wherein the preview machine is a test environment with configuration parameters consistent with the online environment mirror; generating a result report based on the test result of each test case, and sending the result report to the target object. This allows for automated testing without affecting real users and business operations, achieving testing completion in a single operation, reducing operation time, and lowering the error rate due to human error.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a testing method, apparatus, device, and storage medium. Background Technology

[0002] A checklist is a series of standardized verification cases executed according to predetermined testing procedures before new product features are deployed to the production environment. Its main function is to verify the compatibility of new functional modules with existing systems through systematic regression testing, ensuring the stability of core functions and the consistency of end-user experience during software iteration.

[0003] Currently, the technology for executing backend checklists in online environments mainly relies on manual operation. Specifically, this process includes the following steps: (1) manually logging into the jump server of the online environment; (2) manually modifying or updating the required verification scripts; and (3) manually executing the verification scripts and checking the interface response results.

[0004] However, the above method requires logging into the jump server, manually executing the script, and then manually checking the interface response results, execution logs, and database status. It involves multiple steps, is highly dependent on manual operation, is cumbersome, and time-consuming. Furthermore, it relies on individual experience, making it prone to errors and potentially leading to inaccurate test results. Summary of the Invention

[0005] This application provides a testing method, apparatus, device, and storage medium to reduce operation time and error rate.

[0006] In a first aspect, embodiments of this application provide a testing method, the method comprising: In response to a test execution request triggered by the target object, retrieve the list of test cases; For each test case in the test case list, perform the following operations: based on the interface request data corresponding to a test case, send an interface request to the preview machine, obtain the execution result corresponding to the test case, verify the execution result, and determine the test result of a test case; wherein, the preview machine is a test environment with configuration parameters consistent with the online environment image; Based on the test results of each test case, a results report is generated and sent to the target object.

[0007] In one optional embodiment, the execution results include: interface response data, pipeline data, and log data; Then, based on the interface request data corresponding to a test case, an interface request is sent to the preview machine to obtain the execution result corresponding to the test case, including: Based on the interface request data corresponding to a test case, an interface request is initiated to the preview machine, and the interface response data returned by the preview machine is received; wherein, the interface request data includes a request identifier; Based on the request identifier, retrieve transaction data from the transaction database, and based on the request identifier, retrieve log data from the log platform.

[0008] In an optional embodiment, before initiating an interface request to the preview machine based on the interface request data corresponding to a test case, the method further includes: Obtain a request parameter template corresponding to a test case. The request parameter template contains at least one dynamic parameter placeholder. Parse at least one dynamic parameter placeholder to obtain the actual parameter value corresponding to at least one dynamic parameter placeholder; Fill the request parameter template with at least one actual parameter value to obtain the interface request data.

[0009] In one optional embodiment, verifying the execution result and determining the test result of a test case includes: When the interface response data meets the preset first verification condition, the transaction data meets the preset second verification condition, and the log data meets the preset third verification condition, the test result of a test case is determined to be successful.

[0010] In one optional embodiment, a results report is generated based on the test results of each test case, including: The test results of each test case are summarized to obtain the summary result; By concatenating the basic information of at least one failed test case in the test case list whose test result is characterized as failure, the failure result is obtained. The summary results and failure results are combined into a results report.

[0011] In an optional embodiment, after sending the result report to the target object, the method further includes: In response to a retry test execution request triggered by the target object, the retry test execution request carries basic information about at least one failed test case; Based on the basic information of at least one failed test case, obtain a list of retry test cases, which includes at least one failed test case. For each failed test case in the retry test case list, perform the following operations: based on the interface request data corresponding to a failed test case, send an interface request to the preview machine, obtain the retry execution result corresponding to a failed test case, verify the retry execution result, and determine the retry test result of a failed test case; Based on the test results of each failed test case, a retry result report is generated and sent to the target object.

[0012] In an alternative embodiment, the interface request data further includes a test identifier to ensure that the pipeline data and logs contain the test identifier.

[0013] Secondly, embodiments of this application also provide a testing apparatus, the apparatus comprising: The acquisition module is used to retrieve a list of test cases in response to a test execution request triggered by the target object. The testing module is used to perform the following operations for each test case in the test case list: send an interface request to the preview machine based on the interface request data corresponding to a test case, obtain the execution result corresponding to a test case, verify the execution result, and determine the test result of a test case; wherein, the preview machine is a test environment with configuration parameters consistent with the online environment image; The generation module is used to generate a results report based on the test results of each test case and send the results report to the target object.

[0014] In one optional embodiment, the execution results include: interface response data, pipeline data, and log data; When a test module sends an interface request to the preview machine based on the interface request data corresponding to a test case and obtains the execution result corresponding to the test case, it is also used for: Based on the interface request data corresponding to a test case, an interface request is initiated to the preview machine, and the interface response data returned by the preview machine is received; wherein, the interface request data includes a request identifier; Based on the request identifier, retrieve transaction data from the transaction database, and based on the request identifier, retrieve log data from the log platform.

[0015] In an optional embodiment, before initiating an interface request to the preview machine based on the interface request data corresponding to a test case, the test module is further configured to: Obtain a request parameter template corresponding to a test case. The request parameter template contains at least one dynamic parameter placeholder. Parse at least one dynamic parameter placeholder to obtain the actual parameter value corresponding to at least one dynamic parameter placeholder; Fill the request parameter template with at least one actual parameter value to obtain the interface request data.

[0016] In an optional embodiment, when verifying the execution result and determining the test result of a test case, the test module is further configured to: When the interface response data meets the preset first verification condition, the transaction data meets the preset second verification condition, and the log data meets the preset third verification condition, the test result of a test case is determined to be successful.

[0017] In an optional embodiment, when generating a results report based on the test results of each test case, the generation module is further configured to: The test results of each test case are summarized to obtain the summary result; By concatenating the basic information of at least one failed test case in the test case list whose test result is characterized as failure, the failure result is obtained. The summary results and failure results are combined into a results report.

[0018] In an optional embodiment, the apparatus further includes a retry module, which, after sending the result report to the target object, is used to: In response to a retry test execution request triggered by the target object, the retry test execution request carries basic information about at least one failed test case; Based on the basic information of at least one failed test case, obtain a list of retry test cases, which includes at least one failed test case. For each failed test case in the retry test case list, perform the following operations: based on the interface request data corresponding to a failed test case, send an interface request to the preview machine, obtain the retry execution result corresponding to a failed test case, verify the retry execution result, and determine the retry test result of a failed test case; Based on the test results of each failed test case, a retry result report is generated and sent to the target object.

[0019] In an alternative embodiment, the interface request data further includes a test identifier to ensure that the pipeline data and logs contain the test identifier.

[0020] Thirdly, embodiments of this application also provide an electronic device, including: Processor; and Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the test method as described in the first aspect.

[0021] Fourthly, embodiments of this application also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the test method as described in the first aspect.

[0022] Fifthly, this application provides a computer program product that, when invoked by a computer, causes the computer to perform the test method steps as described in the first aspect.

[0023] The beneficial effects of this application are as follows: In the testing method provided in this application embodiment, in response to a test execution request triggered by the target object, a test case list is obtained. Then, for each test case in the test case list, the following operations are performed: an interface request is initiated to the preview machine based on the interface request data corresponding to a test case, the execution result corresponding to a test case is obtained, and the execution result is verified to determine the test result of a test case. The preview machine is a test environment with configuration parameters consistent with the online environment mirror. Finally, based on the test results of each test case, a result report is generated and sent to the target object. This reduces manual execution steps. The target object only needs to trigger a test execution request to perform the most realistic and effective testing without affecting real users and business operations. Testing can be completed in a single operation, greatly reducing operation time. Simultaneously, maintaining a unified test case list, with different target objects using the same list, reduces the operational risks for different target objects during testing. Furthermore, automated test verification reduces the error rate caused by human error.

[0024] Furthermore, other features and advantages of this application will be set forth in the following description and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described herein are used to provide a further understanding of this application, constitute a part of this application, and do not constitute an improper limitation of this application. In the accompanying drawings: Figure 1 This is a schematic diagram of an optional system architecture applicable to the embodiments of this application.

[0026] Figure 2 This is a schematic diagram illustrating the implementation process of a testing method provided in an embodiment of this application.

[0027] Figure 3 This is a logical diagram of a testing method provided in an embodiment of this application.

[0028] Figure 4 This is a schematic diagram of a testing device provided in an embodiment of this application.

[0029] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0031] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0032] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0033] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0034] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0035] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0036] (1) Preview machine: A standalone device or environment specifically designed for integration testing, development debugging, and pre-release verification of new functional modules. This environment provides the development team with an isolated simulation testing space by mirroring the configuration parameters of the production environment, supporting key quality assurance activities such as functional integrity assessment, performance benchmark testing, and user experience verification before the official release of the version.

[0037] (2) Bastion Host: A bastion host deployed in a network security isolation zone, serving as an authorized relay node for cross-security domain access. This device employs strict access control policies and auditing mechanisms. Core functions include: establishing secure channels under network logical isolation conditions; permission control based on the RBAC model; auditing and tracing of remote operation and maintenance; and secure access through multi-factor authentication.

[0038] Based on the above explanations of terms and related terminology, the design concept of the embodiments of this application will be briefly introduced below: Currently, the technology for executing backend checklists in online environments mainly relies on manual operation. Specifically, this process includes the following steps: (1) manually logging into the jump server of the online environment; (2) manually modifying or updating the required verification scripts; and (3) manually executing the verification scripts and checking the interface response results.

[0039] However, the above method requires logging into the jump server, manually executing the script, and then manually checking the interface response results, execution logs, and database status. It involves multiple steps, is highly dependent on manual operation, is cumbersome, and time-consuming. Furthermore, it relies on individual experience, making it prone to errors and potentially leading to inaccurate test results.

[0040] In view of this, this application provides a testing method, which may include: responding to a test execution request triggered by a target object, obtaining a list of test cases, and then performing the following operations for each test case in the list: initiating an interface request to a preview machine based on the interface request data corresponding to a test case, obtaining the execution result corresponding to a test case, verifying the execution result, and determining the test result of a test case. The preview machine is a test environment with configuration parameters consistent with the online environment mirror. Finally, based on the test results of each test case, a result report is generated and sent to the target object. This reduces the number of manual steps; the target object only needs to trigger a test execution request to perform the most realistic and effective testing without affecting real users and business operations. This achieves testing with a single operation, greatly reducing operation time. Simultaneously, maintaining a unified test case list, with different target objects using the same list, reduces the operational risks for different target objects during testing, and automating test verification reduces the error rate caused by human error.

[0041] In particular, the preferred embodiments of this application will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments of this application and the features in the embodiments can be combined with each other without conflict.

[0042] See Figure 1 The diagram illustrates an optional system architecture applicable to an embodiment of this application. This system architecture may include: terminal devices (101a, 101b) and server 102. The terminal devices (101a, 101b) and server 102 can interact via a communication network. The communication network may employ wireless communication or wired communication methods. For example, the terminal devices (101a, 101b) can access the network and communicate with server 102 via cellular mobile communication technology. This cellular mobile communication technology may include, for example, 5G (5th generation mobile networks) or next-generation mobile communication technology. Optionally, the terminal devices (101a, 101b) can access the network and communicate with server 102 via short-range wireless communication. This short-range wireless communication method may include, for example, wireless fidelity (Wi-Fi) technology.

[0043] This application embodiment does not impose any limitation on the number of communication devices involved in the above system architecture. For example, the above system architecture may include more terminal devices, or it may include fewer terminal devices, or it may also include other network devices. Figure 1 As shown, only terminal devices (101a, 101b) and server 102 are described as examples. The following is a brief introduction to the above communication devices and their respective functions.

[0044] A terminal device (101a, 101b) is a device that can provide voice and / or data connectivity to a user, and may be a device that supports wired and / or wireless connections.

[0045] For example, terminal devices (101a, 101b) may include, but are not limited to: mobile phones, tablets, laptops, handheld computers, mobile internet devices (MID), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminal devices in industrial control, wireless terminal devices in autonomous driving, wireless terminal devices in smart grids, wireless terminal devices in transportation safety, wireless terminal devices in smart cities, or wireless terminal devices in smart homes, etc.

[0046] In addition, the terminal devices (101a, 101b) may have related clients installed. The client may be software, such as an application (APP), browser, short video software, etc., or a webpage, mini-program, etc. It should be noted that the terminal devices (101a, 101b) in this application embodiment may be test-related clients.

[0047] Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The target object triggers a test execution request on its terminal device. The terminal device sends the test execution request to the server, which responds by running the checklist script. The checklist script executes asynchronously. The checklist script execution process includes: obtaining a list of test cases, and then performing the following operations for each test case in the list: initiating an interface request to the preview machine based on the interface request data corresponding to a test case, obtaining the execution result corresponding to a test case, verifying the execution result, and determining the test result of a test case. The preview machine is a test environment with configuration parameters consistent with the online environment mirror. Finally, based on the test results of each test case, a result report is generated and sent to the target object.

[0048] The following describes the testing method provided by the exemplary embodiments of this application in conjunction with the above-described system architecture and with reference to the accompanying drawings. It should be noted that the above-described system architecture is only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this respect.

[0049] See Figure 2The diagram shown illustrates the implementation flow of a testing method provided in this application embodiment. Taking a server as an example, the specific implementation flow of this method is as follows: S20: In response to a test execution request triggered by the target object, obtain a list of test cases.

[0050] In this embodiment of the application, when the target object triggers a test execution request on the terminal device, the terminal device sends a test execution request to the server. In response to the test execution request, the server connects to the test case database and obtains a list of test cases from the test case database.

[0051] The test execution request triggered by the target object on the terminal device may be triggered by the target object clicking the control to start the test, or by the target object giving a voice instruction to start the test. This embodiment does not impose any restrictions on this.

[0052] The test case list includes multiple test cases, for example, 20 test cases.

[0053] Optionally, in this embodiment, the test case list can be updated to obtain a new test case list. Update operations include adding test cases, modifying test cases, and deleting test cases. For example, if a new test case A is created, test case A is added to the test case list to obtain a new test case list.

[0054] Additionally, it's worth noting that in this embodiment, access control and frequency control are implemented to reduce the impact on online data. Specifically, the target object is an object with testing permissions and / or test case editing permissions. Frequency control controls the number of times a test execution request is responded to and / or the number of times each test case is used; however, this embodiment does not impose any restrictions on these aspects.

[0055] S21: Perform the following operations for each test case in the test case list: send an interface request to the preview machine based on the interface request data corresponding to a test case, obtain the execution result corresponding to a test case, verify the execution result, and determine the test result of a test case.

[0056] The preview machine is a test environment with configuration parameters identical to the online environment. Execution results include: interface response data, pipeline data, and logs. Interface response data is the data content directly returned by the preview machine in response to interface requests. Pipeline data refers to the core data records that document changes in business status triggered by a single business operation. The content of pipeline data includes, but is not limited to: user ID, request time, decision result, and status. Logs refer to the detailed text records output by the application, middleware, and system in the online environment during operation. They record the complete process and details of the system's internal execution. The test result of a test case indicates whether the test case was executed successfully.

[0057] In this embodiment of the application, for each test case in the test case list, the following operations are performed one by one in the execution order: based on the interface request data corresponding to the current test case, an interface request is initiated to the preview machine to obtain the execution result corresponding to the current test case, and the execution result is verified to determine the test result of the current test case.

[0058] Optionally, in this embodiment of the application, a possible implementation is provided for initiating an interface request to the preview machine based on the interface request data corresponding to a test case, and obtaining the execution result corresponding to a test case, specifically by performing the following operations: S210: Initiate an interface request to the preview machine based on the interface request data corresponding to a test case, and receive the interface response data returned by the preview machine.

[0059] The interface request data includes the request identifier.

[0060] In this embodiment of the application, before initiating an interface request to the preview machine based on the interface request data corresponding to a test case and receiving the interface response data returned by the preview machine, the interface request data corresponding to a test case is first obtained. Optionally, in this embodiment of the application, a possible implementation is provided for obtaining the interface request data corresponding to a test case, specifically by performing the following operations: SA1: Get the request parameter template corresponding to a test case.

[0061] The request parameter template contains at least one dynamic parameter placeholder, as well as request data such as the target URL and request method.

[0062] In this embodiment of the application, the request parameter template corresponding to the test case is obtained from the configuration information of the test case.

[0063] SA2: Parse at least one dynamic parameter placeholder and obtain the actual parameter value corresponding to at least one dynamic parameter placeholder.

[0064] SA3: Fill at least one actual parameter value into the request parameter template to obtain the interface request data.

[0065] For example, suppose a test case verifies that the user balance query interface functions correctly. The request parameter template for this test case contains: "userId": "${dynamic_userId}". Then, at least one dynamic parameter placeholder for this test case is "dynamic_userId". Parse the "dynamic_userId" placeholder and retrieve the actual parameter value of "dynamic_userId" from a pre-defined test data pool (e.g., a user table) or upstream output. Assuming the actual parameter value is 100001, add the actual parameter value 100001 to the request parameter template, resulting in: "userId": "100001".

[0066] This allows for greater focus on designing test templates and parameters, rather than worrying about the details of concatenating the underlying requests, thus reducing the difficulty of writing and maintaining test cases.

[0067] Furthermore, it is worth noting that the interface request data in this embodiment may also include a test identifier. The interface request data includes the test identifier, and during testing, the pipeline data and logs corresponding to the test cases contain the test identifier. In this way, by using the test identifier to distinguish normal online traffic and controlling the storage of test-related pipeline data and logs from being processed and consumed, the system can easily distinguish between test data and real business data. This allows for separate management of test data, avoids contamination of real data, and enables precise cleanup after testing.

[0068] S211: Based on the request identifier, retrieve transaction data from the transaction database and log data from the log platform.

[0069] For example, if the request identifier is 100, then query the transaction database for transaction data containing the request identifier 100, and query the log platform for log data containing the request identifier 100.

[0070] Optionally, in this embodiment of the application, when verifying the execution result of a test case and determining the test result of a test case, if the interface response data meets the preset first verification condition, the transaction data meets the preset second verification condition, and the log data meets the preset third verification condition, the test result of a test case is determined to be successful. Otherwise, the test result of a test case is determined to be unsuccessful.

[0071] In this embodiment of the application, when determining whether the interface response data meets the preset first verification condition, it is detected whether the interface response data is consistent with the expected response data. If they are consistent, it is determined that the interface response data meets the preset first verification condition.

[0072] In this embodiment of the application, when determining whether the transaction data meets the preset second verification condition, it is detected whether the status of the core field of the transaction data is consistent with the expectation (such as whether the status field is SUCCESS). If they are consistent, it is determined that the transaction data meets the preset second verification condition.

[0073] In this embodiment of the application, when determining whether the log data meets the preset third verification condition, it is detected whether the interface parameter transmission in the log data is successful. If successful, it is determined that the log data meets the preset third verification condition.

[0074] Optionally, in this embodiment, it can first be determined whether the interface response data meets a preset first verification condition. If the interface response data meets the preset first verification condition, then it can be determined whether the transaction data meets a preset second verification condition. If the transaction data meets the preset second verification condition, then it can be determined whether the log data meets a preset third verification condition. If any condition is not met, the verification is stopped, and the test result of the test case is determined to be a failure.

[0075] This approach clarifies that verification extends beyond the surface response of the interface, delving into the business data persistence layer (streaming data) and the internal system operation layer (log data). It achieves comprehensive, multi-layered verification, transforming manual verification into automated decision-making based on clearly defined rules. This eliminates the uncertainty of human factors and ensures the consistency and objectivity of test results. When tests fail, log data provides developers with the most direct clues for troubleshooting, accelerating problem localization and remediation, and improving overall operational efficiency.

[0076] S22: Based on the test results of each test case, generate a result report and send the result report to the target object.

[0077] The methods for sending the results report to the target object include, but are not limited to, email, instant messaging tools, internal network systems, etc., and this application embodiment does not impose any restrictions on this.

[0078] Optionally, in this application embodiment, a possible implementation for generating a result report based on the test results of each test case is provided, specifically by performing the following operations: S220: Summarize the test results of each test case to obtain the summary result.

[0079] In this embodiment of the application, after obtaining the test results of each test case, the test results of each test case are summarized to obtain a summary result.

[0080] S221: Concatenate the basic information of at least one failed test case in the test case list whose test result is characterized as failure to obtain the failure result.

[0081] The basic information includes the name and unique identifier of the corresponding failed test case, and may also include the number of the corresponding failed test case, etc., but this application embodiment does not impose any restrictions on this.

[0082] For example, in the test case list, the test cases whose test results are characterized as failure include: test case 1 and test case 3. The identifier of test case 1 is identifier 1 and the name of test case 1 is name 1. The identifier of test case 3 is identifier 3 and the name of test case 3 is name 3. Then the failure result is "identifier 1-name 1; identifier 3-name 3".

[0083] S222: Combine the summary results and failure results into a results report.

[0084] In this embodiment of the application, the summary results and failure results are summarized to obtain the final result report.

[0085] In this way, the generated results report not only indicates whether it was successful or not, but also accurately locates the problem points (failed test cases), enabling the target audience to quickly focus on the problem and improve the efficiency of problem-solving.

[0086] Optionally, in this embodiment of the application, the summary results may be sent to the target object as a result report only, and this embodiment of the application does not impose any restrictions on this.

[0087] Optionally, in this embodiment, all steps following the test execution request triggered by the target object are encapsulated in a checklist script. Specifically, this includes: obtaining a list of test cases; initiating an interface request to the preview machine based on the interface request data corresponding to a test case, obtaining the execution result corresponding to the test case, verifying the execution result, determining the test result of a test case, generating a result report based on the test result of each test case, and sending the result report to the target object. When the server responds to the test execution request triggered by the target object, it runs the checklist script to automate the entire testing process, reducing execution time, operational risks, and error rates, and improving efficiency.

[0088] Based on the above embodiments, see Figure 3The diagram shown illustrates the logic of the testing method in this embodiment. External triggers include: instruction triggering (test execution request), server login, triggering the checklist script, and instruction termination. The execution flow of the checklist script includes: triggering the checklist script, creating a database connection, reading the test case list, traversing the test case list and executing each case sequentially, summarizing all test results, and automatically pushing the results to a specified triggering channel. Each test case execution includes: assembling parameter request interfaces, obtaining response and log data, requesting an external log platform to obtain execution log data, automatically verifying data, and determining whether the current test case's result is successful. When summarizing all test results, if there are failed test cases, the name and identifier of the failed test case are concatenated.

[0089] Furthermore, in this embodiment, after sending the result report to the target object, the failed test cases corresponding to the failed results can be retested, avoiding retesting all test cases and greatly saving testing resources and time. Optionally, in this embodiment, a possible implementation for retesting failed test cases is provided, specifically by performing the following operations: SB1: Responds to a retry test execution request triggered by the target object.

[0090] The retry test execution request carries basic information about at least one failed test case.

[0091] SB2: Based on the basic information of at least one failed test case, obtain a list of retry test cases.

[0092] The retry test case list includes at least one failed test case.

[0093] In this embodiment of the application, when the target object triggers a retry test execution request on the terminal device, the terminal device sends a retry test execution request to the server. In response to the retry test execution request, the server connects to the test case database and obtains a list of retry test cases from the test case database based on the basic information of at least one failed test case.

[0094] SB3: For each failed test case in the retry test case list, perform the following operations: based on the interface request data corresponding to a failed test case, send an interface request to the preview machine, obtain the retry execution result corresponding to a failed test case, verify the retry execution result, and determine the retry test result of a failed test case.

[0095] In this embodiment of the application, the process of executing each failed test case is the same as the process of executing test cases described above.

[0096] SB4: Based on the test results of each failed test case, generate a retry result report and send the retry result report to the target object.

[0097] In this embodiment of the application, the process of generating a retry result report and sending the retry result report to the target object is the same as the aforementioned process of generating a result report and sending the result report to the target object.

[0098] Furthermore, based on the same technical concept, embodiments of this application provide a testing apparatus for implementing the above-described method flow of embodiments of this application. For example, see [link to relevant documentation]. Figure 4 As shown, the testing device 400 may include: an acquisition module 401, a testing module 402, a generation module 403, and a retry module 404.

[0099] Module 401 is used to retrieve a list of test cases in response to a test execution request triggered by the target object. Test module 402 is used to perform the following operations for each test case in the test case list: send an interface request to the preview machine based on the interface request data corresponding to a test case, obtain the execution result corresponding to a test case, verify the execution result, and determine the test result of a test case; wherein, the preview machine is a test environment with configuration parameters consistent with the online environment image; The generation module 403 is used to generate a result report based on the test results of each test case and send the result report to the target object.

[0100] In one optional embodiment, the execution results include: interface response data, pipeline data, and log data; When a test module 402 sends an interface request to the preview machine based on the interface request data corresponding to a test case and obtains the execution result corresponding to the test case, it is also used to: Based on the interface request data corresponding to a test case, an interface request is initiated to the preview machine, and the interface response data returned by the preview machine is received; wherein, the interface request data includes a request identifier; Based on the request identifier, retrieve transaction data from the transaction database, and based on the request identifier, retrieve log data from the log platform.

[0101] In an optional embodiment, before initiating an interface request to the preview machine based on the interface request data corresponding to a test case, the test module 402 is further configured to: Obtain a request parameter template corresponding to a test case. The request parameter template contains at least one dynamic parameter placeholder. Parse at least one dynamic parameter placeholder to obtain the actual parameter value corresponding to at least one dynamic parameter placeholder; Fill the request parameter template with at least one actual parameter value to obtain the interface request data.

[0102] In an optional embodiment, when verifying the execution result and determining the test result of a test case, the test module 402 is further configured to: When the interface response data meets the preset first verification condition, the transaction data meets the preset second verification condition, and the log data meets the preset third verification condition, the test result of a test case is determined to be successful.

[0103] In an optional embodiment, when generating a result report based on the test results of each test case, the generation module 403 is further configured to: The test results of each test case are summarized to obtain the summary result; By concatenating the basic information of at least one failed test case in the test case list whose test result is characterized as failure, the failure result is obtained. The summary results and failure results are combined into a results report.

[0104] In an optional embodiment, after the result report is sent to the target object, the retry module 404 is used to: In response to a retry test execution request triggered by the target object, the retry test execution request carries basic information about at least one failed test case; Based on the basic information of at least one failed test case, obtain a list of retry test cases, which includes at least one failed test case. For each failed test case in the retry test case list, perform the following operations: based on the interface request data corresponding to a failed test case, send an interface request to the preview machine, obtain the retry execution result corresponding to a failed test case, verify the retry execution result, and determine the retry test result of a failed test case; Based on the test results of each failed test case, a retry result report is generated and sent to the target object.

[0105] In an alternative embodiment, the interface request data further includes a test identifier to ensure that the pipeline data and logs contain the test identifier.

[0106] Based on the description of the method and apparatus embodiments above, an exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method according to an embodiment of the present invention.

[0107] This application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0108] This application also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0109] See Figure 5 The diagram shown below illustrates the structure of an electronic device 500 that can serve as a server or client in this application, and is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0110] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0111] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, output unit 507, storage unit 508, and communication unit 509. Input unit 506 can be any type of device capable of inputting information to electronic device 500. Input unit 506 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 507 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 508 may include, but is not limited to, disks and optical discs. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth devices, WiFi devices, worldwide interoperability for microwave access (WiMax) devices, cellular communication devices, and / or the like.

[0112] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above. For example, in some embodiments, the above-described test methods can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. In some embodiments, the computing unit 501 can be configured to perform the above-described test methods by any other suitable means (e.g., by means of firmware).

[0113] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0114] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0115] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device, PLD) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0116] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0117] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0118] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0119] Furthermore, it should be understood that the above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of this invention are still within the scope of this application.

Claims

1. A testing method, characterized in that, include: In response to a test execution request triggered by the target object, retrieve the list of test cases; For each test case in the test case list, the following operations are performed: based on the interface request data corresponding to a test case, an interface request is sent to the preview machine to obtain the execution result corresponding to the test case, and the execution result is verified to determine the test result of the test case; wherein, the preview machine is a test environment with configuration parameters consistent with the online environment image; Based on the test results of each test case, a result report is generated and sent to the target object.

2. The method as described in claim 1, characterized in that, The execution results include: interface response data, transaction data, and log data; The step of initiating an interface request to the preview machine based on the interface request data corresponding to a test case, and obtaining the execution result corresponding to the test case, includes: An interface request is initiated to the preview machine based on the interface request data corresponding to a test case, and the interface response data returned by the preview machine is received; wherein, the interface request data includes a request identifier; Based on the request identifier, the transaction data is obtained from the transaction database, and based on the request identifier, the log data is obtained from the log platform.

3. The method as described in claim 2, characterized in that, Before initiating an interface request to the preview machine based on the interface request data corresponding to a test case, the process also includes: Obtain the request parameter template corresponding to the test case, wherein the request parameter template contains at least one dynamic parameter placeholder; Parse the at least one dynamic parameter placeholder to obtain the actual parameter value corresponding to the at least one dynamic parameter placeholder; The obtained at least one actual parameter value is filled into the request parameter template to obtain the interface request data.

4. The method as described in claim 2, characterized in that, Verifying the execution result and determining the test result of a test case includes: When the interface response data meets the preset first verification condition, the transaction data meets the preset second verification condition, and the log data meets the preset third verification condition, the test result of the test case is determined to be successful.

5. The method as described in claim 1, characterized in that, The generation of a result report based on the test results of each test case includes: The test results of each test case are summarized to obtain the summary result; By concatenating the basic information of at least one failed test case in the test case list whose test result is characterized as failure, the failure result is obtained. The summary results and the failure results are combined into a results report.

6. The method as described in claim 5, characterized in that, After sending the result report to the target object, the process further includes: In response to a retry test execution request triggered by the target object, the retry test execution request carries basic information about the at least one failed test case; Based on the basic information of the at least one failed test case, a retry test case list is obtained, the retry test case list including the at least one failed test case; For each failed test case in the retry test case list, perform the following operations: based on the interface request data corresponding to a failed test case, send an interface request to the preview machine, obtain the retry execution result corresponding to the failed test case, verify the retry execution result, and determine the retry test result of the failed test case; Based on the test results of each failed test case, a retry result report is generated and sent to the target object.

7. The method as described in claim 2, characterized in that, The interface request data also includes a test identifier, so that the transaction data and the log contain the test identifier.

8. A testing apparatus, characterized in that, include: The acquisition module is used to retrieve a list of test cases in response to a test execution request triggered by the target object. The testing module is used to perform the following operations for each test case in the test case list: initiate an interface request to the preview machine based on the interface request data corresponding to a test case, obtain the execution result corresponding to the test case, and verify the execution result to determine the test result of the test case; wherein, the preview machine is a test environment with configuration parameters consistent with the online environment mirror; The generation module is used to generate a result report based on the test results of each test case, and send the result report to the target object.

9. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method as described in any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images