Private test method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a privatization test method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: receiving a test starting request; the test starting request is sent after a timed task is triggered; executing a test case which is packaged in a Docker mirror image and corresponds to the test starting request, and generating a test report according to a preset structure; the test case is used for simulating the interaction process with the application service. By adopting the method, the operation and maintenance cost can be reduced.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a privatization testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Art

[0002] With the rapid development of software development technology, testing technology has emerged. Manual testing methods have always been the main means of software testing. Manual testing relies on testers to execute test cases one by one, record test results and find defects.

[0003] However, with the increasing complexity of software systems, manual testing has gradually exposed many shortcomings. Manually executing a large number of test cases is time-consuming and labor-intensive, and it is difficult to meet the needs of rapid iteration development; the test coverage is limited and it is impossible to fully detect all functions of the system. Therefore, automated testing applications are born. Automated testing uses various testing tools and frameworks to achieve automatic execution of test cases, automatic verification of results, and automatic generation of reports.

[0004] However, in a private environment, it is impossible to obtain test cases from outside for automated testing. Therefore, in a private environment, manual testing is still used, but manual testing is inefficient, which leads to high operation and maintenance costs. Summary of the invention

[0005] Based on this, it is necessary to provide a privatized testing method, apparatus, computer equipment, computer-readable storage medium and computer program product that can reduce operation and maintenance costs in response to the above technical problems.

[0006] In a first aspect, the present application provides a privatization testing method, comprising:

[0007] Receive a test start request; the test start request is sent after the scheduled task is triggered;

[0008] Execute the test case encapsulated in the Docker image and corresponding to the test start request, and generate a test report according to a preset structure; the test case is used to simulate the interaction process with the application service.

[0009] In one embodiment, before receiving the test start request, the method further includes:

[0010] Obtain the test case, dependency information and Docker file; the dependency information includes the environment dependency required by the test case when running; the Docker file is used to define the construction process of the Docker image;

[0011] Encapsulate the test case in the Docker image based on the test case, the dependency information and the Docker file through a Docker build command;

[0012] The packaged Docker image and the application service are deployed in the same environment.

[0013] In one embodiment, executing a test case encapsulated in a Docker image and corresponding to the test start request includes:

[0014] Scanning the annotations through the test framework to determine the test case corresponding to the test start request;

[0015] The test case is executed according to the preset rules of the test framework.

[0016] In one embodiment, the execution process of the test case includes:

[0017] Constructing a test request according to the test parameters defined in the test case;

[0018] Sending the test request to the application service;

[0019] Receive response data sent by the application service; the response data is generated by the application service after executing corresponding business logic based on the test request.

[0020] In one embodiment, the test request and the response data are sent through a preset interface; before sending the test request to the application service, the method further includes:

[0021] One or more of availability detection, interface specification verification, and data format verification are performed on the preset interface.

[0022] In one embodiment, the method further comprises:

[0023] Extract key information from the test report;

[0024] In the case where there is alarm content in the key information, generating alarm information according to the alarm content;

[0025] When the existence of external network resources is detected, the alarm information is sent to the target object.

[0026] In a second aspect, the present application also provides a privatized testing device, comprising:

[0027] A receiving module, used to receive a test start request; the test start request is sent after the scheduled task is triggered;

[0028] The execution module is used to execute the test case encapsulated in the Docker image and corresponding to the test start request, and generate a test report according to a preset structure; the test case is used to simulate the interaction process with the application service.

[0029] In a third aspect, the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any one of the above-mentioned implementation methods when executing the computer program.

[0030] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any one of the above-mentioned methods.

[0031] In a fifth aspect, the present application also provides a computer program product, including a computer program, which implements the steps of any one of the above-mentioned methods when executed by a processor.

[0032] The above-mentioned privatization test method, apparatus, computer equipment, computer-readable storage medium and computer program product receive a test start request, and after receiving the test start request, encapsulate the test case in a Docker image for execution. The Docker container provides an isolated and controllable operating environment, so that the test case can be executed in the same way on different systems and platforms, and automated testing can be performed in a privatization environment, thereby reducing operation and maintenance costs. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0034] Figure 1 A schematic diagram of a privatization test method in one embodiment;

[0035] Figure 2 A schematic diagram of a privatization environment in one embodiment;

[0036] Figure 3 is a structural block diagram of a privatized test device in an embodiment;

[0037] Figure 4 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0039] In one embodiment, Figure 1 As shown, a privatization test method is provided. This embodiment uses the method applied to a terminal as an example for illustration. It can be understood that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0040] Step 102, receiving a test start request; the test start request is sent after the scheduled task is triggered.

[0041] The test start request is triggered and sent by a scheduled task. When the system is running, the scheduled task is automatically executed according to the preset time period. These scheduled tasks can be configured through the system's scheduling mechanism, such as Cron, Kubernetes' CronJob, etc., to ensure that the test tasks are triggered on time. The role of the scheduled task is to automatically start the test without manual intervention, thereby ensuring the continuity and consistency of the test work.

[0042] Optionally, once the scheduled task is triggered, the system will receive a test start request through a predetermined interface. The test start request usually contains some key information, such as the test case identifier to be executed, the application service identifier, and related configuration parameters. This request is sent to the test framework via the HTTP protocol or a message queue. After receiving the request, the system will parse the request content, first find the corresponding test case based on the test case identifier in the request, and analyze the application service identifier in the request to determine the target service or application for the test. At this point, the test framework will begin to prepare the relevant execution environment, including checking whether the required resources are available and whether a new test environment or application service container needs to be pulled. After receiving the complete test start request, the test framework will begin to schedule the execution of the corresponding test case to ensure that the test proceeds smoothly according to the predetermined process.

[0043] Step 104, execute the test case encapsulated in the Docker image and corresponding to the test start request, and generate a test report according to a preset structure; the test case is used to simulate the interaction process with the application service.

[0044] After receiving the test start request, the system will execute the test case encapsulated in the Docker image. Each test case is encapsulated into an independent Docker image, which contains all the environments and dependencies required to execute the test case. This ensures the consistency and repeatability of the test environment, and the test can run as expected regardless of the hardware or operating system environment.

[0045] For example, after the test case is started in the Docker container, the system will automatically execute the test process according to the parameter configuration in the test request. For example, the test case will simulate the interaction process with the target application service. For Web applications, the test case may interact with the server through HTTP requests to verify the correctness of the request and response; for API services, the test case will send different requests and check whether the returned response data meets expectations. The test case will use preset input parameters to operate and simulate different user behaviors to verify the function, performance and stability of the application service.

[0046] Optionally, the system will record detailed log information and execution data for each step of the test process. These logs and execution results will be organized and stored for subsequent report generation. The status of the test case execution, running time, success or failure, etc. will be recorded. After execution, the test framework will generate a test report based on this information according to the predetermined structure.

[0047] Optionally, test reports are usually generated through a framework like Allure. The Allure framework can generate structured reports based on the execution status of test cases, such as passed, failed, skipped, etc. The report will show the execution results of each test case and related error information.

[0048] Furthermore, if a test case fails, the report will include detailed error logs to help developers locate the problem. The structure of the report is usually divided into modules, functions, test scenarios, etc., which is convenient for team members to view and analyze.

[0049] One point that needs to be explained is that this method is applied in a privatized environment, which refers to non-public application services and infrastructure hosted within an enterprise or organization. These services are usually subject to strict security, compliance requirements and environment customization. Application services in privatized environments are usually deployed in internal server clusters or virtualization platforms. These services may vary due to factors such as network configuration, operating system version, and dependent software version. Therefore, in this application, test cases are encapsulated and executed by utilizing Docker containerization technology. Docker containers can package all application environments, dependencies, and test cases themselves in an independent image, thereby ensuring the consistency and isolation of the test process in a privatized environment. Through Docker images, the test environment is standardized, ensuring that the execution results of test cases at different times and on different machines are consistent, which is especially important for privatized environments because they often rely on diverse and highly customized internal services. Exemplary, combined with Figure 2 As shown, Figure 2 A schematic diagram of a privatization environment in one embodiment.

[0050] In the above privatization test method, a test start request is received. After receiving the test start request, the test case is encapsulated in a Docker image for execution. The Docker container provides an isolated and controllable operating environment, so that the test case can be executed in the same way on different systems and platforms, and automated testing can be performed in a privatization environment, thereby reducing operation and maintenance costs.

[0051] In one embodiment, before the above-mentioned receiving of the test start request, it also includes: obtaining test cases, dependency information and Docker files; the dependency information includes the environment dependencies required for the test cases when running; the Docker file is used to define the building process of the Docker image; through the Docker build command, based on the test cases, dependency information and Docker files, the test cases are encapsulated in the Docker image; the encapsulated Docker image and the application service are deployed in the same environment.

[0052] Before receiving the test start request, the system first needs to obtain the relevant test cases, dependency information and Docker files. Among them, the test case is the core of the automated test. The test case defines the test scenario, input parameters, expected output and the steps of interacting with the application service; the dependency information includes the various environment configurations and dependency libraries required by the test case during operation. The dependency information ensures the consistency and stability of the test environment; the Docker file is used to define the Docker image building process, which describes in detail how to package the test case and all the required environments and dependencies into an independent container to ensure the repeatability and isolation of the test.

[0053] Optionally, after obtaining the test cases, the system will further confirm the dependency information of these test cases. Dependency information usually includes but is not limited to operating system environment requirements, programming language runtime, database connection configuration, external API service interface, etc. This dependency information is the key to ensure that the test cases can be successfully executed in the correct environment. If the test case needs to rely on certain specific versions of libraries or services, then before executing the test, the system needs to confirm that these dependencies have been met or have been correctly configured.

[0054] Next, the system will obtain the Docker file, which is a script used to define how to build a Docker image. The Docker file will contain multiple instructions, such as "FROM", "RUN", "COPY", etc. These instructions define the base image of the image, how to install dependencies, copy files, configure environment variables, and other operations. The system will execute the Docker build command based on the obtained Docker file and dependency information to generate a Docker image containing the test case and its dependencies. By executing the Docker build command, the system encapsulates all dependency information and test cases into an independent image. This image contains all the environments required to execute the test, ensuring that the test can be executed consistently in a private environment. No matter which node or machine it runs on, this image can ensure complete consistency of the environment. The benefit of Docker containerization is that it can completely isolate the execution environment of the test case and is not affected by changes in the external environment, thus ensuring the reliability and repeatability of the test results.

[0055] Optionally, after building the Docker image, you need to deploy the packaged Docker image and the application service to the same environment. In this way, the test case and the tested application service are in the same network and system environment, which can simulate the real application interaction process. This deployment method ensures the stability of the test process, ensures that the interaction between the test case and the application service can be executed smoothly as expected, and avoids problems caused by environmental differences.

[0056] Optionally, all specific execution cases are placed in the main package, and each module creates its own sub-package to manage and organize test cases. This structural design not only helps improve the maintainability of the code, but also meets the need to generate a clear test report directory.

[0057] In the above embodiment, by obtaining test cases, dependency information and Docker files, the system can ensure the correctness of all environments and dependencies in the process of building Docker images, thereby ensuring the efficiency and consistency of the test. Deploying test cases and application services in the same environment further improves the stability of the test and the reliability of execution, ensuring that the test results can accurately reflect the status of the application service.

[0058] In one embodiment, the above-mentioned execution of the test case corresponding to the test start request encapsulated in the Docker image includes: performing annotation scanning through the test framework to determine the test case corresponding to the test start request; and executing the test case according to the preset rules of the test framework.

[0059] After receiving the test start request, the system needs to execute the test cases encapsulated in the Docker image. This process includes scanning the annotations through the test framework, determining the test cases corresponding to the test start request, and executing these test cases according to the preset rules of the test framework. This step ensures that the test cases are executed in the correct environment and can generate valid test results according to the preset rules.

[0060] First, before executing the test, the system needs to perform annotation scanning on the test cases through the test framework. Test frameworks usually use annotations, such as the @Test annotation in JUnit or @Test in TestNG, to identify test methods and test cases. Annotations are not only used to identify test cases, but also to provide some additional configuration information for test cases, such as dependencies, priorities, timeouts, etc. The test framework scans the annotations in the code at startup to identify which methods are test cases and which methods are part of the test. By scanning these annotations, the framework can find the corresponding test case based on the test case identifier carried in the test startup request.

[0061] For example, a test start request may contain a test case ID or name, and the framework uses this information to locate the specific test class and test method. Each test case may be a method or a group of methods, which are mapped to a specific function or scenario defined in the framework. Through annotation scanning, the framework can identify the test cases that need to be executed, and determine the execution order, dependencies, and execution environment based on this information.

[0062] Optionally, the preset rules may be one or more of test sequence, environment configuration, exception handling, and test data management.

[0063] Among them, test order means that some test cases may depend on the execution results of other test cases, and the framework needs to execute them in the correct order; environment configuration means that the test framework may configure different environments according to the needs of the test cases, such as setting environment variables, database connections, file paths, etc., to ensure that the test cases can be executed in the correct environment; exception handling means that the framework will automatically capture exceptions during the execution of test cases, handle unexpected situations, and record relevant log information to ensure stability during the test execution process; test data management means that the test framework usually prepares the required test data before execution, and cleans it up after the test is completed to ensure that it will not affect subsequent tests.

[0064] Furthermore, in one embodiment, the execution process of the above test case includes: constructing a test request according to the test parameters defined in the test case; sending the test request to the application service; receiving response data sent by the application service; the response data is generated after the application service executes the corresponding business logic based on the test request.

[0065] In this embodiment, the interaction between actual user requests and application services is simulated to ensure that the application services can correctly respond to various types of requests and return expected results.

[0066] First, the test case builds a test request based on its defined test parameters. Each test case contains some parameters when it is executed. These parameters are usually pre-defined in the test case to provide necessary information for the test request. Test parameters can include but are not limited to request method, request URL, request header, and request body.

[0067] Then, through the test framework, the system will automatically build a complete test request based on these test parameters. The constructed test request includes all necessary information and is ready to be sent to the application service for processing. Then, the constructed test request is sent to the application service via the HTTP protocol or other related communication protocols. After receiving the request, the application service will execute the corresponding business logic according to the parameters carried in the request. This business logic may involve operations on the database, calls to external services, data processing, etc. In this process, the application service performs necessary business judgments and processing based on the content of the request, and finally generates response data. Optionally, the response data may include a response status code, a response header, and a response body.

[0068] Optional. After the test framework receives the response data, it will check it against the expected result of the test case. The framework verifies whether the status code in the response data meets the expected, whether the data in the response body meets the requirements of the test case, and whether the response header is correct. For example, if the test case expects the result of a query operation, the framework will check whether the returned data contains the correct fields and data types, and compare it with the expected query result.

[0069] Optionally, if all parameters of the test request and response meet expectations, the framework marks the test case as passed; if there is anything that does not meet expectations, the framework will record detailed error information, including the wrong status code, response body content, missing or mismatched fields, etc., and mark it as failed. Finally, the framework summarizes the test results and generates a report, which contains the execution status, execution time, error details, and other information of each test case for the development team to analyze and improve the application service.

[0070] Furthermore, in one embodiment, the above test request and response data are sent through a preset interface; before sending the test request to the application service, it also includes: performing one or more of availability detection, interface specification verification and data format verification on the preset interface.

[0071] Before the test case is executed, the test framework must first ensure the availability and standardization of the preset interface, which is crucial to ensure the smooth execution of the entire test process. The preset interface is the communication bridge between the application service and the test case during the test process. Therefore, before sending a test request, these interfaces must be fully checked to avoid test failures caused by interface problems.

[0072] Optionally, the test framework will perform an availability check on the preset interface. The main purpose of this step is to confirm whether the interface is normally reachable and can respond to requests correctly. For example, the framework can verify whether the interface can return a 200OK status code by sending a simple GET request. If the interface does not respond or returns an incorrect status code, such as 404 or 500, it means that the interface is unavailable and the test will not be able to continue. Availability testing ensures that the test request can be sent smoothly to the application service and receive the expected response.

[0073] Optionally, the framework will also perform interface specification verification. The purpose of this step is to verify whether the interface is designed and implemented in the manner specified in the document, and to ensure that the interface behaves as expected. In the interface specification verification, the test framework checks whether the request method, URL path, request header, and request parameters meet the specifications. For example, the interface should support the HTTP methods listed in the document, such as GET, POST, PUT, DELETE, etc., and be able to handle the specified URL path and query parameters. The framework will also check whether the request header contains the necessary authentication information, Content-Type, etc., and ensure that the interface can correctly parse these request headers. Only after passing the interface specification verification, the test framework will consider the interface to meet the design requirements and be ready for further testing.

[0074] Optionally, data format verification is also an important part of interface pre-check. During the test process, the data exchanged between the application service and the test framework is usually in a structured format, such as JSON or XML. Therefore, the framework ensures that the data format of the request body and the response body meets expectations. For example, the test framework verifies whether the request body is JSON format data that meets the interface requirements, checks whether the fields are complete, and whether the data types match. Similarly, the framework also verifies whether the data format of the response body is correct, ensuring that the returned data conforms to the format specified in the interface document. If the field type in the response body is incorrect or the data format does not meet expectations, the framework will mark it as an error and report it to the developer for repair.

[0075] In this embodiment, it can be ensured that before the test case is executed, the preset interface can correctly accept the request and return the response according to the specification.

[0076] In one embodiment, the above invention also includes: extracting key information in the test report; generating alarm information based on the alarm content when there is alarm content in the key information; and sending the alarm information to the target object when the existence of external network resources is monitored.

[0077] After the test case is executed, the test framework will parse the generated test report according to the preset rules and extract the key information. The test report usually contains a lot of execution details, including test results, execution time, successful and failed cases, exception information, etc. In order to facilitate subsequent monitoring and problem tracking, the test framework will filter out key information from the report, such as failed test cases, response time limit exceeded, incorrect response content, etc.

[0078] If alarm content is found in the test report, the framework will further process this information. Alarm content usually indicates that an abnormal or unexpected situation occurred during the test, such as the response time of the application service exceeded the preset threshold, some use cases failed to execute, or the interface returned an incorrect status code. The test framework will generate corresponding alarm information based on the alarm content. Alarm information usually includes the alarm type, such as failure, timeout, error, a specific description of the alarm, such as a certain interface request failed, a certain use case failed to execute, and possible solutions or repair steps. The generation of alarm information not only helps developers quickly locate problems, but also provides a basis for subsequent decision-making and response.

[0079] When external network resources are detected, the test framework will send the generated alarm information to the target object. External network resources refer to external services or tools connected to the test system, such as the enterprise's internal alarm management system, monitoring platform, and chat tools. When the alarm information is generated, the framework will push this information to the relevant target object in real time through the preset network interface to ensure that relevant personnel can quickly receive the alarm and take appropriate actions. The process of sending alarm information usually includes sending the alarm content to the target object via HTTP, Webhook, email or other notification mechanisms to ensure that the alarm can be delivered to the application operation and maintenance personnel or developers in a timely manner.

[0080] Through automated alarm notifications, problems can be quickly discovered and responded to during the test process. This is especially important for private deployment environments, because the deployment of test and production environments often involves complex network topologies, configurations, and permissions. Through the integration of external network resources, cross-environment and cross-network alarm notifications can be implemented, helping developers and operations personnel identify and solve problems in a timely manner, thereby improving system stability and reliability.

[0081] In the present embodiment, the automatic processing of the alarm information also greatly improves the efficiency of the test process. It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the indications of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there are clear instructions in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0082] Based on the same inventive concept, the embodiment of the present application also provides a privatization test device for implementing the privatization test method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more privatization test device embodiments provided below can refer to the limitations on the privatization test method above, and will not be repeated here.

[0083] In an exemplary embodiment, Figure 3 As shown, a privatization test device is provided, including: a receiving module and an execution module, wherein:

[0084] The receiving module 310 is used to receive a test start request; the test start request is sent after the scheduled task is triggered.

[0085] The execution module 320 is used to execute the test case encapsulated in the Docker image and corresponding to the test start request, and generate a test report according to a preset structure; the test case is used to simulate the interaction process with the application service.

[0086] In one embodiment, the above device further includes a configuration module, and the configuration module includes:

[0087] The acquisition unit is used to obtain test cases, dependency information, and Docker files; the dependency information includes the environment dependencies required by the test cases when running; the Docker file is used to define the building process of the Docker image.

[0088] The encapsulation unit is used to encapsulate the test case in the Docker image based on the test case, dependency information, and Docker file through the Docker build command.

[0089] The deployment unit is used to deploy the packaged Docker image and application service in the same environment.

[0090] In one embodiment, the execution module includes:

[0091] The scanning unit is used to perform annotation scanning through the test framework to determine the test case corresponding to the test start request.

[0092] The selection unit is used to execute test cases according to the preset rules of the test framework.

[0093] In one embodiment, the execution module further includes:

[0094] The request building unit is used to build a test request according to the test parameters defined in the test case.

[0095] The request sending unit is used to send a test request to the application service.

[0096] The response unit is used to receive the response data sent by the application service; the response data is generated by the application service after executing the corresponding business logic based on the test request.

[0097] In one embodiment, the execution module further includes:

[0098] The detection unit is used to perform one or more of availability detection, interface specification verification and data format verification on the preset interface.

[0099] In one embodiment, the above device further includes a warning module, and the warning module includes:

[0100] Extraction unit, used to extract key information from the test report.

[0101] The information generating unit is used to generate alarm information according to the alarm content when the key information contains the alarm content.

[0102] The sending unit is used to send the alarm information to the target object when the existence of external network resources is detected.

[0103] Each module in the above-mentioned privatization test device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

[0104] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 4 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store test data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a privatization test method is implemented.

[0105] Those skilled in the art will understand that Figure 4The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0106] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps of the method in the above embodiment when executing the computer program.

[0107] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method in the above embodiment are implemented.

[0108] In one embodiment, a computer program product is provided, including a computer program, which implements the steps of the method in the above embodiment when executed by a processor.

[0109] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0110] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0111] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A privatization testing method, characterized in that: The method comprises: Receive a test start request; the test start request is sent after the scheduled task is triggered; Execute the test case encapsulated in the Docker image and corresponding to the test start request, and generate a test report according to a preset structure; the test case is used to simulate the interaction process with the application service.

2. The method according to claim 1, characterized in that Before receiving the test start request, the method further includes: Obtain the test case, dependency information and Docker file; the dependency information includes the environment dependency required by the test case when running; the Docker file is used to define the construction process of the Docker image; Encapsulate the test case in the Docker image based on the test case, the dependency information and the Docker file through a Docker build command; The packaged Docker image and the application service are deployed in the same environment.

3. The method according to claim 1, characterized in that The executing the test case encapsulated in the Docker image and corresponding to the test start request includes: Scanning the annotations through the test framework to determine the test case corresponding to the test start request; The test case is executed according to the preset rules of the test framework.

4. The method according to claim 3, characterized in that The execution process of the test case includes: Constructing a test request according to the test parameters defined in the test case; Sending the test request to the application service; Receive response data sent by the application service; the response data is generated by the application service after executing corresponding business logic based on the test request.

5. The method according to claim 4, characterized in that The test request and the response data are sent through a preset interface; before sending the test request to the application service, the method further includes: One or more of availability detection, interface specification verification, and data format verification are performed on the preset interface.

6. The method according to claim 1, characterized in that The method further comprises: Extract key information from the test report; In the case where there is alarm content in the key information, generating alarm information according to the alarm content; When the existence of external network resources is detected, the alarm information is sent to the target object.

7. A privatized testing device, characterized in that: The device comprises: A receiving module, used to receive a test start request; the test start request is sent after the scheduled task is triggered; The execution module is used to execute the test case encapsulated in the Docker image and corresponding to the test start request, and generate a test report according to a preset structure; the test case is used to simulate the interaction process with the application service.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

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

Images