Method for flexibly constructing test environment as required and software test system
By building standard and special testing environments, using traffic interceptors and docker containers to manage test environment and interface information files, the problems of unstable testing environment, inaccurate data, and waste of resources in the existing technology are solved, and the accuracy of test data and resource conservation effects are achieved.
Patent Information
- Application Number
- CN202411976226.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-31
- Publication Date
- 2025-04-15
AI Technical Summary
The existing technology cannot provide a stable and accurate testing environment, resulting in inaccurate functional verification, high cost of maintaining interface information files, serious waste of physical resources, and long period of joint testing function.
By building standard test environments and special test environments, using traffic interceptors and docker containers to quickly start and destroy the test environment, and manage interface information files based on Git to ensure data accuracy and resource recycling.
It realizes the accuracy of test data, reduces hardware costs, maintains the latest status of interface information files, saves physical resources, and shortens the joint testing cycle.
Smart Images
Figure CN119829471A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer data processing, and in particular to a method for flexibly constructing a test environment on demand and a software testing system. Background Art
[0002] At present, the methods for standardizing the test environment in the industry have not reached a standard that is flexible enough to deal with various types of tests. Especially when it comes to cross-component debugging, it is necessary to provide accurate basic data for a stable test environment for routine test verification, and to be compatible with the debugging of components in the joint test during the development and verification process. At this stage, multiple joint test environments have to be built according to different test requirements.
[0003] A stable test environment is difficult to maintain because it mixes released and unreleased functions, and there is a large amount of junk data, which is not conducive to verifying the correctness of the tested functions.
[0004] The maintenance of interface information documents often stays at the initial development stage. Subsequent adjustments and updates lead to high document update costs and easily make the interface information files inaccurate.
[0005] The need to support a large number of test scenarios requires too many test servers, resulting in a waste of physical resources.
[0006] In summary, the current testing status has the following deficiencies: 1. It is always impossible to provide a stable and accurate test environment for functional verification. 2. A large amount of junk data affects the accuracy of functional testing and cannot achieve the purpose of real functional testing. 3. A large number of interface information files need to be maintained, and the final documents cannot play a real guiding role, wasting a lot of manpower costs. 4. A large number of physical resources are idle and wasted, resulting in a waste of costs. 5. The joint test function has too much junk data in the test environment, which lengthens the functional test cycle. Summary of the invention
[0007] The purpose of the present invention is to provide a method for flexibly constructing a test environment on demand and a software testing system, which aims to overcome the above-mentioned problems existing in the prior art.
[0008] To achieve the above object, the present invention provides the following technical solutions: A method for flexibly building a test environment on demand includes the following steps: The method comprises the steps of (1) building a test environment; the test environment comprises a standard test environment and at least one special test environment; Step (2), add a traffic interceptor to the test environment; Step (3), if the software to be tested X and the software to be tested Y need to jointly test a function, then add a test identifier A to the traffic request header of the software to be tested X; add the test identifier A to the software to be tested Y, and use it as a special test environment, that is, the software to be tested Y environment with the test identifier A; Further, the method further comprises the following steps: Step (4), when the request traffic of the software to be tested X is sent, a software to be tested Y environment with a test identifier A is started through the docker container, and the corresponding software to be tested service is registered in the traffic interceptor; Step (5): the traffic interceptor identifies whether the request traffic of the software to be tested X carries the test identifier A; if it carries the test identifier A, the traffic interceptor forwards the request traffic of the software to be tested X to the environment of the software to be tested Y carrying the test identifier A for joint testing.
[0009] Furthermore, the step (5) further includes: if there is no test identifier A, the traffic interceptor forwards the request traffic of the software to be tested X to the standard test environment.
[0010] Furthermore, in the above step (1), when setting up the test environment, a version management warehouse, namely, a public warehouse M, is defined outside of all software; the above public warehouse M includes multiple sub-warehouses, and different sub-warehouses are used to manage the interface information files of each interface respectively.
[0011] Furthermore, the public warehouse M is a project created based on Git, and the software to be tested X and the software to be tested Y are code libraries under the project. Through the version management mechanism of Git, the interface information file can be version managed.
[0012] Furthermore, in the above step (1), the interface definition for the joint test of the software under test X and the software under test Y is specifically as follows: the software under test Y submits the interface information file of the interface P to the public warehouse M; the software under test X retrieves and obtains the interface information file of the interface P through the public warehouse M; according to the interface information file of the interface P, the software under test X and the software under test Y each develop and complete their own interface information.
[0013] Furthermore, the above step (5) also includes returning the result data of the joint test and storing the result data in a MySQL database with a test identifier A.
[0014] Furthermore, in the above step (4), after the joint test is completed, the software to be tested X and the software to be tested Y with the test identification A are destroyed, and the registration information of the corresponding software to be tested service is automatically removed from the traffic interceptor, thereby achieving the purpose of resource recovery.
[0015] A software testing system uses any of the above methods to call the software to be tested and operate the test environment.
[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. Test data accuracy guarantee: The joint test data of new functions will not pollute the data in the stable test environment, and the data accuracy is guaranteed.
[0017] 2. The test environment changes from multiple sets to one set There is always a complete and stable test environment (i.e., standard test environment) to provide daily verification, and the feature environment can be flexibly created on demand to verify new functions, saving hardware costs.
[0018] 3. The interface information file is always up to date and accurate When setting up the test environment, a version management repository is defined based on Git outside of all software, which is used as a public repository M for the specifications and definitions of interface information files. Through Git's version management mechanism, interface information files (including interface definition files and interface description files) can be version managed, so that the interface information files are always in the latest and accurate state, and can also support historical tracing, interface information retrieval and other capabilities.
[0019] 4. Flexible construction of special test environment through docke-compose Special test environments are all built with Docker and can be destroyed after use. This ensures correctness while saving machine resources in the test environment, reducing machine investment costs. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] Figure 1 It is the overall flow chart of the present invention.
[0021] Figure 2 This is a management principle diagram of the interface definition file in the present invention. DETAILED DESCRIPTION
[0022] The specific implementation of the present invention is described below with reference to the accompanying drawings. In order to fully understand the present invention, many details are described below, but for those skilled in the art, the present invention can be implemented without these details.
[0023] like Figure 1 and Figure 2 As shown, a method for flexibly building a test environment on demand includes the following steps: The method comprises the steps of (1) building a test environment; the test environment comprises a standard test environment and at least one special test environment.
[0024] Specifically, when setting up the test environment, a version management warehouse is defined outside all software, namely, a public warehouse M. The public warehouse M includes multiple sub-warehouses, and different sub-warehouses are used to manage the interface information files of various interfaces respectively. Preferably, the public warehouse M is a project created based on Git, and the software to be tested X and the software to be tested Y are the code libraries under the project. Through the version management mechanism of Git, the interface information files (including interface definition files and interface description files) can be version managed.
[0025] Through the above operations, based on the management of interface information files in Git, it is possible to retrieve interface information files, track change history records, obtain information on interface responsible persons, manage interface versions, etc. This ensures the accuracy of interface definition files.
[0026] like Figure 1 and Figure 2 As shown, for example, when setting up a test environment, the interface definition for joint testing of software to be tested X and software to be tested Y is as follows: (1.1) The software under test Y submits the interface information file of interface P to the public warehouse M.
[0027] (1.2) The software under test X retrieves and obtains the interface information file of interface P through the public warehouse M.
[0028] (1.3) According to the interface information file of interface P, software X to be tested and software Y to be tested each develop their own interface information and complete the development.
[0029] In addition, to ensure the accuracy of the data, when setting up a test environment, you can desensitize some of the data from the production environment and construct it in this test environment.
[0030] Step (2), add a traffic interceptor to the test environment. The traffic interceptor is used to distinguish whether the request traffic of the software under test is traffic in the standard test environment or traffic in the special test environment. For example, add a test identifier A to the traffic request header, where A represents a Class A special test environment. If the test identifier is not identified in the request header, it is considered to be request traffic in the standard test environment and no special processing is performed.
[0031] Step (3): If the software to be tested X and the software to be tested Y need to jointly test a function, a test identifier A is added to the traffic request header of the software to be tested X; a test identifier A is added to the software to be tested Y, and the software to be tested is used as a special test environment, i.e., the environment of the software to be tested Y with the test identifier A.
[0032] Step (4): When the request traffic of the software to be tested X is sent, a software to be tested Y environment with test identifier A is quickly started through the Docker container, including the dependent database of the test identifier A, and the corresponding software to be tested service is registered in the traffic interceptor.
[0033] Step (5), the traffic interceptor identifies whether the request traffic of the software to be tested X carries the test identifier A; If the request flow of the software to be tested X contains the test mark A, the flow interceptor forwards the request flow of the software to be tested X to the environment of the software to be tested Y with the test mark A for joint testing; returns the result data of the joint testing, and stores the result data in the MySQL database with the test mark A. After the joint testing is completed, the software to be tested X and the software to be tested Y with the test mark A are destroyed, and the registration information of the corresponding software to be tested service is automatically removed from the flow interceptor to achieve the purpose of resource recovery.
[0034] If the request traffic of the software to be tested X does not carry the test identifier A, the traffic interceptor forwards the request traffic of the software to be tested X to the standard test environment for normal testing without any special processing.
[0035] In addition, the present invention discloses a software testing system, which uses any of the above methods to call the software to be tested and operate the test environment.
[0036] The above is only a specific implementation of the present invention, but the design concept of the present invention is not limited thereto. Any non-substantial changes to the present invention using this concept shall be deemed as an infringement of the protection scope of the present invention.
Claims
1. A method for flexibly constructing a test environment on demand, comprising step (1), constructing a test environment, characterized in that: The test environment includes a standard test environment and at least one special test environment. The method further includes the following steps: Step (2), add a traffic interceptor to the test environment; Step (3): If the software to be tested X and the software to be tested Y need to jointly test a function, a test identifier A is added to the traffic request header of the software to be tested X; a test identifier A is added to the software to be tested Y, and the software to be tested is used as a special test environment, i.e., the environment of the software to be tested Y with the test identifier A.
2. The method for flexibly constructing a test environment on demand according to claim 1, characterized in that: The following steps are also included: Step (4): When the request traffic of the software to be tested X is sent, a software to be tested Y environment with a test identifier A is started through the docker container, and the corresponding software to be tested service is registered in the traffic interceptor; Step (5), the traffic interceptor identifies whether the request traffic of the software to be tested X carries the test identifier A; If it carries the test mark A, the traffic interceptor forwards the request traffic of the software to be tested X to the environment of the software to be tested Y with the test mark A for joint testing.
3. The method for flexibly constructing a test environment on demand according to claim 2, characterized in that: The following steps are also included: The step (5) also includes: if there is no test identifier A, the traffic interceptor forwards the request traffic of the software to be tested X to the standard test environment.
4. The method for flexibly constructing a test environment on demand according to claim 1, characterized in that: In the step (1), when setting up the test environment, a version management warehouse, namely, a public warehouse M, is defined outside all software; the public warehouse M includes multiple sub-warehouses, and different sub-warehouses are used to manage the interface information files of each interface respectively.
5. The method for flexibly constructing a test environment on demand according to claim 4, characterized in that: The public warehouse M is a project created based on Git, and the software to be tested X and the software to be tested Y are code libraries under the project; through the version management mechanism of Git, the interface information file can be version managed.
6. The method for flexibly constructing a test environment on demand according to claim 5, characterized in that: In the step (1), the interface definition for the joint test of the software to be tested X and the software to be tested Y is specifically as follows: the software to be tested Y submits the interface information file of the interface P to the public warehouse M; the software to be tested X retrieves and obtains the interface information file of the interface P through the public warehouse M; according to the interface information file of the interface P, the software to be tested X and the software to be tested Y each develop and complete their own interface information.
7. The method for flexibly constructing a test environment on demand according to claim 1, characterized in that: The step (5) also includes returning the result data of the joint test and storing the result data in a MySQL database with a test identifier A.
8. A method for flexibly constructing a test environment on demand according to claim 2 or 7, characterized in that: The step (5) further includes, after the joint test is completed, destroying the software to be tested X and the software to be tested Y with the test identification A, and automatically removing the registration information of the corresponding software to be tested service from the traffic interceptor.
9. A software testing system, characterized in that: The software testing system uses the method described in any one of claims 1 to 8 to call the software to be tested and operate the test environment.