Software testing method, device, electronic device and storage medium

Abstract

This application relates to the field of fintech technologies, and discloses a software testing method, apparatus, electronic device, and storage medium. The method is applied to a front-end system, and includes: obtaining a transaction request sent by an external system; obtaining transaction attributes from the transaction request; matching the transaction attributes with transaction attribute verification conditions in a configuration file; if the transaction attributes in the transaction request match the transaction attribute verification conditions, forwarding the transaction request to a first computing device, where a target software of a version to be tested deployed in the first computing device processes the transaction request, and determining a test result of the version to be tested according to the processing result of the target software of the version to be tested for the transaction request; if the transaction attributes in the transaction request do not match the transaction attribute verification conditions, forwarding the transaction request to a second computing device. This application can reduce the impact on the back-end system due to software testing failures.

Description

Technical Field

[0001] This application relates to the technical field of fintech, and more particularly, to a software testing method, apparatus, electronic device, and storage medium. Background Art

[0002] In the related art, due to the need of transaction services, the transaction functions that the post-system needs to undertake are increasing. Therefore, in order to meet the transaction needs, it is necessary to update the version of the target software deployed in the post-system for transaction processing. However, during the testing process of the new version of the target software, if it is determined that the verification of the new version of the target software fails, it is necessary to roll back the new version of the target software, that is, the entire post-system is shut down. During the shutdown process of the post-system, transaction requests cannot be processed normally. Summary of the Invention

[0003] In view of the above problems, embodiments of this application propose a software testing method, apparatus, electronic device, and storage medium to solve the problem of the overall shutdown of the post-system caused by the failure of the new version of software testing in the related art.

[0004] According to one aspect of the embodiments of this application, a software testing method is provided, which is applied to a front-end system. The front-end system is communicatively connected to a post-system. The post-system includes a first computing device and a second computing device. The second computing device refers to other computing devices in the post-system that deploy the target software except the first computing device. The to-be-tested version of the target software is deployed on the first computing device, and the version of the target software deployed on the second computing device is lower than the to-be-tested version. The front-end system stores a configuration file corresponding to the to-be-tested version of the target software. The configuration file includes transaction attribute verification conditions configured for the to-be-tested version and the target network address of the first computing device. The method includes: obtaining a transaction request sent by an external system; obtaining transaction attributes from the transaction request; matching the transaction attributes with the transaction attribute verification conditions in the configuration file; if the transaction attributes in the transaction request match the transaction attribute verification conditions, forwarding the transaction request to the first computing device, and the to-be-tested version of the target software deployed in the first computing device processes the transaction request, and determines the test result of the to-be-tested version according to the processing result of the to-be-tested version of the target software on the transaction request; if the transaction attributes in the transaction request do not match the transaction attribute verification conditions, forwarding the transaction request to the second computing device to process the transaction request through the target software deployed in the second computing device.

[0005] In some embodiments of the present application, before matching the transaction attributes with the transaction attribute verification conditions in the configuration file, the method further includes: after the service in the front-end system is started, obtaining the modification time of the configuration file in the memory; if it is determined that the modification time of the configuration file in the memory is different from the last modification time of the configuration file in the cache, loading the configuration file in the memory into the cache; the matching of the transaction attributes with the transaction attribute verification conditions in the configuration file includes: reading the transaction attribute verification conditions from the loaded configuration file; and matching the transaction attributes with the read transaction attribute verification conditions.

[0006] In some embodiments of the present application, after obtaining the modification time of the configuration file in the memory after the service in the front-end system is started, the method further includes: if it is determined that the modification time of the configuration file in the memory is the same as the last modification time of the configuration file in the cache, reading the transaction attribute verification conditions from the configuration file in the cache; the matching of the transaction attributes with the transaction attribute verification conditions in the configuration file includes: matching the transaction attributes with the transaction attribute verification conditions read from the cache.

[0007] In some embodiments of the present application, the method further includes: determining the status of the verification switch in the configuration file; if the status of the verification switch is the open state, performing the step of obtaining the transaction attributes from the transaction request.

[0008] In some embodiments of the present application, after determining the status of the verification switch in the configuration file, the method further includes: if the status of the verification switch is the closed state, forwarding the transaction request to the second computing device.

[0009] In some embodiments of the present application, the obtaining the transaction attributes from the transaction request includes: obtaining the value of the verification field from the transaction attribute verification conditions, where the value of the verification field is used to indicate the transaction attributes; and extracting the corresponding transaction attributes from the transaction request according to the value of the verification field.

[0010] In some embodiments of the present application, after forwarding the transaction request to the first computing device, the method further includes: receiving the processing result returned by the first computing device; and forwarding the processing result to the external system.

[0011] According to one aspect of the embodiments of the present application, a software testing device is provided, which is applied to a pre-system. The pre-system is communicatively connected to a post-system. The post-system includes a first computing device and a second computing device. The second computing device refers to other computing devices in the post-system that have deployed the target software except the first computing device. The to-be-tested version of the target software is deployed on the first computing device, and the version of the target software deployed on the second computing device is lower than the to-be-tested version. A configuration file corresponding to the to-be-tested version of the target software is stored in the pre-system. The configuration file includes transaction attribute verification conditions configured for the to-be-tested version and the target network address of the first computing device. The device includes: a transaction request acquisition module, configured to acquire a transaction request sent by an external system; a transaction attribute acquisition module, configured to acquire transaction attributes from the transaction request; a matching module, configured to match the transaction attributes with the transaction attribute verification conditions in the configuration file; a first forwarding module, configured to, if the transaction attributes in the transaction request match the transaction attribute verification conditions, forward the transaction request to the first computing device, and the to-be-tested version of the target software deployed in the first computing device processes the transaction request and determines the test result of the to-be-tested version according to the processing result of the to-be-tested version of the target software on the transaction request; a second forwarding module, configured to, if the transaction attributes in the transaction request do not match the transaction attribute verification conditions, forward the transaction request to the second computing device to process the transaction request through the target software deployed in the second computing device. [[ID=!]]

[0012] According to one aspect of the embodiments of the present application, an electronic device is provided, including: a processor; a memory, on which computer-readable instructions are stored. When the computer-readable instructions are executed by the processor, the software testing method as described above is implemented.

[0013] According to one aspect of the embodiments of the present application, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor, the software testing method as described above is implemented.

[0014] Q According to one aspect of the embodiments of the present application, a computer program product is provided, which includes computer instructions. When the computer instructions are executed by a processor, the software testing method as described above is implemented.

[0015] In this application, the target software of the version to be tested is deployed on the first computing device in the back-end system, and the target software of other versions lower than the version to be tested is deployed on the second computing device in the back-end system. In this way, based on the transaction attribute verification conditions in the configuration file, transaction requests used as test cases can be filtered out, and the transaction requests used as test cases are forwarded to the first computing device for processing to test the performance of the target software of the version to be tested deployed on the first computing device. And other transaction requests are forwarded to the second computing device for processing. In this way, even if the test result determines that the target software of the version to be tested deployed on the first computing device fails the verification, it does not affect the second computing device to continue the transaction business processing, nor is it necessary to perform secondary processing on all transaction requests. Only the transaction requests used as test cases need to be processed twice, thereby reducing the impact on the overall transaction business processing of the back-end system caused by the failure of the target software of the version to be tested.

[0016] In addition, if the verification determines that the target software of the version to be tested fails the test, only the first computing device can be shut down and isolated, while the second computing device can continue to provide transaction business processing services, thereby avoiding the situation that the back-end system is completely paralyzed due to the failure of the test during the test process of the target software. Further, since in this application, the front-end system filters the transaction requests that need to be forwarded to the first computing device through the transaction attribute verification conditions in the configuration file, the transaction attribute verification conditions in the configuration file can be modified to make the transaction requests that originally needed to be forwarded to the first computing device for processing be forwarded to the second computing device for processing during the shutdown and isolation process of the first computing device. Brief Description of the Drawings

[0017] The drawings here are incorporated into the specification and form a part of this specification, showing the embodiments consistent with this application, and are used together with the specification to explain the principles of this application. Obviously, the drawings in the following description are only some embodiments of this application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0018] Figure 1 is a schematic diagram of the application scenario of this application shown according to an embodiment of this application.

[0019] Figure 2 is a flowchart of a software testing method shown according to an embodiment of this application.

[0020] Figure 3 is a flowchart of the steps before step 230 shown according to an embodiment of this application.

[0021] Figure 4It is a flowchart of a software testing method shown according to another embodiment of the present application.

[0022] Figure 5 It is a flowchart of a software testing method shown according to a specific embodiment of the present application.

[0023] Figure 6 It is a block diagram of a software testing apparatus shown according to an embodiment of the present application.

[0024] Figure 7 It shows a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present application. Detailed implementation manners

[0025] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more complete and comprehensive, and will fully convey the concept of the example embodiments to those skilled in the art.

[0026] The block diagrams shown in the accompanying drawings are only functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0027] The flowcharts shown in the accompanying drawings are only illustrative and do not necessarily include all the contents and operations / steps, nor do they necessarily need to be executed in the described order. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may be changed according to the actual situation.

[0028] It should be noted that: "a plurality of" mentioned in this article refers to two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after.

[0029] In practice, since the post-system needs to undertake more and more transaction functions, in order to meet the needs of transactions, it is necessary to update the version of the target software. However, during the testing process of the new version of the target software, if it is determined that the verification of the new version of the target software fails, then the new version of the target software needs to be rolled back, that is, the post-system as a whole is shut down, and during the shutdown process of the post-system, transaction request processing cannot be carried out normally.

[0030] Moreover, if the target software of the new version is rolled back, all the transaction requests received during the testing process need to be processed again after the update, which affects the normal transaction business processing of the post - system. Moreover, this results in a long software testing cycle. Based on this, the solution of this application is proposed.

[0031] Figure 1 It is a schematic diagram of the application scenario of this application shown according to an embodiment of this application. As Figure 1 shown, this application scenario includes at least one external system 110, a front - end system 120, and a post - system 130. Among them, the external system 110 is communicatively connected to the front - end system 120 through a wired or wireless network, and the front - end system 120 is communicatively connected to the post - system 130 through a wired or wireless network.

[0032] The post - system includes at least a first computing device 131 and at least one second computing device 132. The first computing device 131 and the second computing device 132 are respectively communicatively connected to the front - end system 120. In this application, the software to be tested is called the target software. Among them, the version of the target software to be tested is deployed on the first computing device 131, and the stable running version of the target software is deployed on the second computing device 132. Or, it can be understood that the version of the target software running on the second computing device 132 is lower than the version of the target software to be tested.

[0033] Among them, the front - end system 120 serves as a channel for the post - system 130 to dock with the external system, or the front - end system 120 is an intermediate business exchange platform between the post - system 130 and the external system. The post - system 130 is used to process transaction services. The front - end system 120 does not have the function of processing transaction services and can only perform message conversion, encryption and decryption processing of messages, communication protocol conversion, and transfer in or out of communication messages through routing functions.

[0034] In practice, there may be multiple external systems communicatively connected to the front - end system 120. Since different external systems use different communication protocols, different external systems may adopt different communication protocols. In this way, the front - end system 120 can uniformly convert the format of the transaction requests initiated by the external systems to convert the transaction requests initiated by the external systems into the format required by the specified communication protocol supported by the post - system 130. Thus, the post - system 130 can focus on processing the transaction requests without having to pay attention to the communication protocols of the received transaction requests. Similarly, after the post - system 130 finishes processing the transaction requests, it sends the transaction requests to the front - end system 120. The front - end system 120 converts the processing results of the transaction requests into the format supported by the external system from which the transaction requests originated, and then forwards the processed results after format conversion to the corresponding external system.

[0035] In some embodiments, the front-end system 120 may also encrypt and decrypt the data transmitted between the back-end system 130 and the external system. That is, the front-end system 120 may decrypt the transaction request received from the external system and then forward the decrypted transaction request to the back-end system 130. Similarly, after receiving the processing result from the back-end system 130, the front-end system 120 encrypts the processing result and then forwards the encrypted processing result to the corresponding external system.

[0036] In a specific embodiment, the front-end system 120 may be a bank front-end system, the back-end system 130 may be a bank back-end system 130, and the external system may be a provident fund system, an old-age insurance system, a medical insurance system outside the bank, or an enterprise system of a certain enterprise (such as a financial system, etc.).

[0037] In this application, for the target software deployed in the back-end system, the to-be-tested version of the target software is deployed on the first computing device in the back-end system, and other versions of the target software (such as a stable running version) are deployed on the second computing device in the back-end system. In this way, with the routing function of the front-end system, some transaction requests initiated by the external system are forwarded to the first computing device for processing to verify the performance of the to-be-tested version of the target software deployed on the first computing device; and other transaction requests initiated by the external system are forwarded to the second computing device for processing. In this way, even if there are abnormalities in the verification of the to-be-tested version of the target software deployed on the first computing device, it will not affect the second computing device to process other transaction requests.

[0038] The implementation details of the technical solution of the embodiments of this application are elaborated in detail below:

[0039] Figure 2 is a flowchart of a software testing method shown according to an embodiment of this application. This method can be executed by an electronic device with processing capabilities, such as a server in the front-end system. This method is applied to the front-end system, and the front-end system is communicatively connected to the back-end system. The back-end system includes a first computing device and a second computing device. The second computing device refers to other computing devices in the back-end system that deploy the target software except the first computing device; the to-be-tested version of the target software is deployed on the first computing device, and the version of the target software deployed on the second computing device is lower than the to-be-tested version; the front-end system stores a configuration file corresponding to the to-be-tested version of the target software, and the configuration file includes transaction attribute verification conditions configured for the to-be-tested version and the target network address of the first computing device. As Figure 2 shown, this method includes steps 210 to 250, which are introduced in detail as follows:

[0040] Step 210, obtain a transaction request sent by an external system.

[0041] The target software refers to the application program in the back-end system for processing transaction services.

[0042] Among them, the external system can be a social security system, a medical insurance system, a provident fund system, an enterprise system, etc., which are not specifically limited herein. The transaction request can be a transfer transaction request, a deduction transaction request, a number binding request, a bill repayment transaction request, etc., which are not specifically limited herein. In a specific embodiment, the external system can also be a test system, and the test system can simulate sending a transaction request as a test case to the front-end system.

[0043] Step 220: Obtain transaction attributes from the transaction request.

[0044] The transaction attribute refers to the information used to reflect the attribute characteristics of the transaction request. The transaction attribute can be a protocol number, an account type, a business type, etc., which are not specifically limited herein. It can be understood that the transaction attributes obtained from the transaction request are equivalent to the specific content of the transaction attributes, or are called the values of the transaction attributes. For example, if the transaction attribute to be obtained is the protocol number, then what is obtained from the transaction request is the specific content of the protocol number, such as the protocol number is 402222.

[0045] In some embodiments, step 220 includes: obtaining the value of the verification field from the transaction attribute verification condition, where the value of the verification field is used to indicate the transaction attribute; extracting the corresponding transaction attribute from the transaction request according to the value of the verification field.

[0046] In some embodiments, the configuration file can be sent from the back-end system to the front-end system. In this case, the developer can configure in the terminal in the back-end system to obtain the configuration file, and then through the communication connection between the back-end system and the front-end system, send the configuration file to the front-end system and store the configuration file in the memory of the front-end system accordingly.

[0047] In some other embodiments, the configuration file can be configured by testers in the front-end system. In this case, the tester can configure in the terminal in the front-end system to obtain the configuration file, and then send the configuration file to the server of the front-end system and store the configuration file in the memory of the server of the front-end system.

[0048] The transaction attribute verification condition is used to define the conditions that the transaction request for the target version to be tested needs to meet. In other words, if the transaction attributes corresponding to a transaction request meet the conditions defined by the transaction attribute verification condition, it is determined that the transaction request is a request for testing the target software of the version to be tested, and the request for testing the target software of the version to be tested can also be understood as the test case corresponding to the target software of the version to be tested.

[0049] In the transaction attribute verification conditions, the transaction attributes to be extracted can be indicated through verification fields. Among them, the verification fields in the transaction attribute verification conditions can be one or more. One verification field is used to indicate one transaction attribute. For example, field A is used to indicate the protocol number, field B is used to indicate the account type, field C is used to indicate the service type, etc. Since the transaction attributes to be verified are indicated by the transaction fields in the transaction attribute verification conditions, therefore, the transaction attributes are extracted according to the values of the transaction fields, ensuring that the transaction attributes for verification can be extracted, and the transaction attributes that are not required for verification in the transaction request do not need to be extracted, thereby avoiding wasting processing resources and storage resources.

[0050] For example, through the transaction attribute verification conditions, it can be specified that transaction requests initiated with a protocol number starting with 40222 are used to test the target software of the version to be tested. For example, the following code is used as the transaction attribute verification condition:

[0051]

[0052] Among them, keyBody is the verification field. In the above code, the value of keyBody is SignSN, and SignSN is used to represent the protocol number. The protocol number specified in the transaction attribute verification conditions is the protocol number starting with 40222. Thus, based on the above attribute verification conditions, the transaction attribute of the protocol number can be extracted from the transaction request, and the specific content of the protocol number corresponding to the transaction request can be obtained, or the value of the protocol number in the transaction request can be obtained.

[0053] In a specific embodiment, the specified verification fields in the transaction attribute verification conditions can be one or more. In this way, when there are multiple specified verification fields in the transaction attribute verification conditions, it correspondingly indicates that there are multiple transaction attributes for verification.

[0054] For example, the following code is used as the transaction attribute verification condition:

[0055]

[0056] Among them, keyHead and keyBody are the verification fields. In the above code, the value of keyHead is MagTp, and MagTp is used to represent the service type; the value of the verification field keyBody is BizTP, and BizTP is used to represent the account type; the above transaction attribute verification conditions indicate that transaction requests with a service type of epcc.211.001.01 and an account type of 13000 or 14000 are used to test the target software of the version to be tested.

[0057] Step 230: Match the transaction attributes with the transaction attribute verification conditions in the configuration file.

[0058] The transaction attribute verification conditions include the reference attribute conditions configured for each transaction attribute. As described above, the transaction attribute verification conditions may include one verification field or multiple verification fields. When the transaction attribute verification conditions include one verification field, the transaction attribute conditions correspondingly include the reference attribute conditions set for the transaction attribute indicated by the verification field. In this case, the attribute content of the transaction attribute extracted from the transaction request is compared with the reference attribute conditions corresponding to the transaction attribute in the transaction attribute verification conditions to determine whether the attribute content of the transaction attribute in the transaction request meets the corresponding reference attribute conditions. If it meets, it is determined that the transaction attribute obtained from the transaction request matches the transaction attribute verification conditions; otherwise, if it does not meet, it is determined that the transaction attribute obtained from the transaction request does not match the transaction attribute verification conditions.

[0059] When the transaction attribute verification conditions include multiple verification fields, the transaction attribute verification conditions indicate the reference attribute conditions respectively corresponding to multiple transaction attributes and the logical operation relationship between the multiple reference attribute conditions. Among them, the logical operation relationship includes logical AND, logical OR, logical NOT, etc. Therefore, the transaction attribute verification conditions are jointly defined by the reference attribute conditions corresponding to multiple transaction attributes and the logical operation relationship between the multiple reference attribute conditions.

[0060] Step 240: If the transaction attributes in the transaction request match the transaction attribute verification conditions, forward the transaction request to the first computing device. The target software of the version to be tested deployed in the first computing device processes the transaction request, and determines the test result of the version to be tested according to the processing result of the target software of the version to be tested on the transaction request.

[0061] As described above, if the transaction attributes in the transaction request match the transaction attribute verification conditions, it indicates that the transaction request is used to test the target software of the version to be tested. Therefore, the transaction request is correspondingly forwarded to the first computing device. Then, the target software of the version to be tested deployed in the first computing device processes the transaction request to obtain the processing result corresponding to the transaction request.

[0062] If the first computing device determines that the processing result of the transaction request is correct, it is necessary to return the processing result of the transaction request to the front-end system. After being processed by the front-end system, the front-end system forwards the processing result to the corresponding external system. That is, after step 240, the method further includes: receiving the processing result returned by the first computing device; forwarding the processing result to the external system. Conversely, if the first computing device determines that the processing result of the transaction request is incorrect, the first computing device can send a processing failure prompt message to the front-end system and send the processing failure prompt message to the front-end system, and the front-end system forwards the processing failure prompt message to the external system.

[0063] In some embodiments, a test management device may also be deployed in the back-end system. The test management device may store the reference processing result corresponding to the transaction request that meets the transaction attribute verification conditions. The reference processing result is the accurate processing result of the transaction request when the processing logic of the target software of the version to be tested for the transaction request is accurate. Thus, after the first computing device processes the received transaction request, the obtained processing result is sent to the test management device. The test management device correspondingly compares the processing result corresponding to the transaction request with the reference processing result. If the two are consistent, it indicates that the processing result of the transaction request is accurate. Conversely, if the two are inconsistent, it indicates that the processing result of the target software of the version to be tested for the transaction request is incorrect.

[0064] Step 250, if the transaction attribute in the transaction request does not match the transaction attribute verification conditions, forward the transaction request to the second computing device to process the transaction request through the target software deployed in the second computing device.

[0065] As described above, if the transaction attribute in the transaction request does not match the transaction attribute verification conditions, it indicates that the transaction request is not for testing the target software of the version to be tested. Therefore, the transaction request is sent to the second computing device, and the target software deployed in the second computing device processes the transaction request.

[0066] After step 250, the method further includes: receiving the processing result returned by the first computing device; forwarding the processing result to the external system. It can be understood that the front-end system may forward the processing result to the corresponding external system after performing protocol conversion or encryption processing on the processing result.

[0067] In the post - system of this application, the target software of the version to be tested is deployed on the first computing device, and the target software of other versions lower than the version to be tested is deployed on the second computing device. In this way, based on the transaction attribute verification conditions in the configuration file, transaction requests used as test cases can be filtered out, and the transaction requests used as test cases are forwarded to the first computing device for processing to test the performance of the target software of the version to be tested deployed on the first computing device. And other transaction requests are forwarded to the second computing device for processing. In this way, even if the test result determines that the target software of the version to be tested deployed on the first computing device fails the verification, it does not affect the second computing device to conduct transaction business processing, nor is it necessary to re - process all transaction requests. Only the transaction requests used as test cases need to be re - processed, thereby reducing the impact on the overall transaction business processing of the post - system caused by the failure of the target software of the version to be tested.

[0068] In addition, if the verification determines that the target software of the version to be tested fails the test, only the first computing device can be shut down and isolated, while the second computing device can continue to provide transaction business processing services, thus avoiding the situation where the post - system is completely paralyzed due to the failure of the test during the testing process of the target software. Further, since in this application, the pre - system filters the transaction requests that need to be forwarded to the first computing device through the transaction attribute verification conditions in the configuration file, the transaction attribute verification conditions in the configuration file can be modified to cause the transaction requests that originally needed to be forwarded to the first computing device for processing to be forwarded to the second computing device for processing during the shutdown and isolation process of the first computing device.

[0069] Further, if it is determined that the target software of the version to be tested passes the test, the target software of the version to be tested can be correspondingly deployed to the second computing device to achieve the full deployment of the target software of the version to be tested in the post - system.

[0070] In some embodiments, as Figure 3 shown, before step 230, the method further includes:

[0071] Step 310, after the service in the pre - system is started, obtain the modification time of the configuration file in the memory.

[0072] Step 320, if it is determined that the modification time of the configuration file in the memory is different from the last modification time of the configuration file in the cache, load the configuration file in the memory into the cache.

[0073] In this embodiment, step 230 includes: reading the transaction attribute verification conditions from the loaded configuration file; matching the transaction attributes with the read transaction attribute verification conditions.

[0074] It can be understood that if the modification time of the configuration file in the memory is different from the last modification time of the configuration file in the cache, it indicates that the configuration file in the memory has been modified compared to the configuration file loaded in the cache. Therefore, in this case, in order to ensure that the transaction request can be accurately identified as a transaction request for testing the target software of the version to be tested, it is necessary to load the configuration file in the memory into the cache to replace the configuration file in the cache.

[0075] Moreover, in this embodiment, after the service in the front-end system is started, it is first determined whether the modification time of the configuration file in the memory is the same as the last modification time of the configuration file in the cache. In this way, in the case where the configuration file in the memory is modified, it can be ensured that the latest configuration file can take effect in real time without restarting the front-end system. Thus, the dynamic update requirement of the configuration file can be met, and the updated configuration file takes effect in real time.

[0076] In some embodiments, after step 310, the method further includes: if it is determined that the modification time of the configuration file in the memory is the same as the last modification time of the configuration file in the cache, read the transaction attribute verification condition from the configuration file in the cache; in this embodiment, step 230 includes: matching the transaction attribute with the transaction attribute verification condition read from the cache.

[0077] That is to say, if the configuration file in the memory is not updated, it indicates that the configuration files in the memory and the cache are the same. Therefore, if it is determined that the modification time of the configuration file in the memory is the same as the last modification time of the configuration file in the cache, directly read the transaction attribute verification condition from the configuration file in the cache without reloading the configuration file in the memory into the cache.

[0078] In some embodiments, as Figure 4 shown, the method further includes:

[0079] Step 410, determine the status of the verification switch in the configuration file.

[0080] If the status of the verification switch is the open state, execute step 220.

[0081] If the status of the verification switch is the closed state, execute step 420 to forward the transaction request to the second computing device.

[0082] The configuration file may include a switch field, and the value of the switch field is used to indicate the status of the verification switch. It can be understood that the value of the switch field includes a value for indicating that the verification switch is in the open state and a value for indicating that the verification switch is in the closed state. Thus, the status of the verification switch in the configuration file can be determined by reading the value of the switch field in the configuration file.

[0083] It is worth mentioning that the modification time of the configuration file in the memory is the same as the last modification time of the configuration file in the cache. In step 410, the status of the verification switch is determined from the configuration file in the cache; when the modification time of the configuration file in the memory is different from the last modification time of the configuration file in the cache, in step 410, the configuration file in the memory is first loaded into the cache, and then the status of the verification switch is determined from the configuration file loaded into the cache.

[0084] When the verification switch is in the open state, it indicates that the target software to be tested needs to be tested at this time. Therefore, it is necessary to match the transaction attributes in the transaction request with the transaction attribute verification conditions; conversely, when the verification switch is in the closed state, it indicates that the target software to be tested does not need to be tested at this time, and correspondingly, it is not necessary to send the transaction request to the first computing device for processing. Therefore, in this case, the transaction requests can be forwarded to the second computing device for processing, and it is not necessary to obtain the transaction attributes from the transaction requests and match the transaction attributes with the transaction attribute verification conditions.

[0085] For example, if it is determined in the previous test that the target software of the version to be tested fails the test and the first computing device needs to be isolated and shut down, the verification switch can be set to the closed state through the value of the verification field in the configuration file. In this way, during the isolation and shutdown process of the first computing device, all transaction requests can be forwarded to the second computing device for processing.

[0086] Figure 5 It is a flowchart of a software testing method shown according to a specific embodiment of the present application. This method can be applied to a front-end system, such as Figure 5 As shown, after the service in the front-end system is started, the following steps 510 - 580 are executed, which are introduced in detail as follows:

[0087] Step 510, monitor transaction requests from an external system.

[0088] Step 520, obtain the transaction request.

[0089] Step 530, determine whether the configuration file has been updated; if not, execute step 540, if it has been updated, execute step 550 to load the configuration file in the memory into the cache. Specifically, it is determined whether the configuration file has been updated by comparing whether the modification time of the configuration file in the memory is the same as the last modification time of the configuration file in the cache, that is, if the two times are the same, it is determined that the configuration file has not been updated; if the two times are different, it is determined that the configuration file has been updated.

[0090] Step 540, read the configuration file in the cache.

[0091] Step 560: Determine whether verification is enabled. If yes, execute Step 570; if no, execute Step 580. Specifically, read the value of the switch field in the configuration file to determine whether verification is enabled. If the value of the switch field in the configuration file indicates that the verification switch is in the on state, it means verification is enabled; if the value of the switch field in the configuration file indicates that the verification switch is in the off state, it means verification is not enabled.

[0092] Step 570: Determine whether the transaction attributes in the transaction request match the transaction attribute verification conditions. If yes, execute Step 571; if no, execute Step 580.

[0093] Step 571: Forward the transaction request to the first computing device.

[0094] Step 580: Forward the transaction request to the second computing device.

[0095] After Step 571 and Step 580, return to execute Step 510.

[0096] Based on the above embodiments, a part of the target software of the version to be tested is released on some computing devices in the post - system (for example, released to one first computing device. Of course, there can also be multiple first computing devices in the post - system), and other versions of the target software are deployed on the second computing devices in the post - system. During the testing of the target software of the version to be tested, the first computing device and the second computing device can jointly provide services. Even if the target software of the version to be tested fails the test, the second computing device can continue to provide services, and the entire post - system will not be rolled back to the shutdown state. Therefore, the solution provided by this embodiment can effectively avoid the situation where the entire post - system shuts down due to the failure of the new version of the software test. Thus, it reduces the impact on the business processing of the post - system caused by the failure of the new version of the software test, and can effectively avoid the situation where a large number of transaction requests are delayed or processed unsuccessfully. Moreover, this solution can reduce the probability of production events occurring in the post - system during the testing of the new version of the target software, greatly improving the security and stability of the post - system. Also, this solution is transparent to the post - system and does not require major modifications to the post - system.

[0097] The following introduces the apparatus embodiments of the present application, which can be used to execute the methods in the above embodiments of the present application. For the details not disclosed in the apparatus embodiments of the present application, please refer to the above method embodiments of the present application.

[0098] Figure 6It is a block diagram of a software testing device shown according to an embodiment of the present application. The software testing device is applied to a front-end system, and the front-end system is communicatively connected to a back-end system. The back-end system includes a first computing device and a second computing device. The second computing device refers to other computing devices in the back-end system that have deployed the target software except the first computing device. The to-be-tested version of the target software is deployed on the first computing device, and the version of the target software deployed on the second computing device is lower than the to-be-tested version. The front-end system stores a configuration file corresponding to the to-be-tested version of the target software. The configuration file includes transaction attribute verification conditions configured for the to-be-tested version and the target network address of the first computing device. As Figure 6 shown, the software testing device includes:

[0099] A transaction request acquisition module 610, configured to acquire a transaction request sent by an external system;

[0100] A transaction attribute acquisition module 620, configured to acquire transaction attributes from the transaction request;

[0101] A matching module 630, configured to match the transaction attributes with the transaction attribute verification conditions in the configuration file;

[0102] A first forwarding module 640, configured to, if the transaction attributes in the transaction request match the transaction attribute verification conditions, forward the transaction request to the first computing device. The to-be-tested version of the target software deployed in the first computing device processes the transaction request, and determines the test result of the to-be-tested version according to the processing result of the to-be-tested version of the target software for the transaction request;

[0103] A second forwarding module 650, configured to, if the transaction attributes in the transaction request do not match the transaction attribute verification conditions, forward the transaction request to the second computing device to process the transaction request through the target software deployed in the second computing device.

[0104] In some embodiments of the present application, the software testing device further includes: a modification time acquisition module, configured to acquire the modification time of the configuration file in the memory after the service in the front-end system is started; a loading module, configured to, if it is determined that the modification time of the configuration file in the memory is different from the last modification time of the configuration file in the cache, load the configuration file in the memory into the cache. In this embodiment, the matching module 630 is further configured to: read the transaction attribute verification conditions from the loaded configuration file; match the transaction attributes with the read transaction attribute verification conditions.

[0105] In some embodiments of the present application, the software testing apparatus further includes: a reading module, configured to, if it is determined that the modification time of the configuration file in the memory is the same as the last modification time of the configuration file in the cache, read the transaction attribute verification conditions from the configuration file in the cache; in this embodiment, the matching module 630 is further configured to: match the transaction attributes with the transaction attribute verification conditions read from the cache.

[0106] In some embodiments of the present application, the software testing apparatus further includes: a status determination module, configured to determine the status of the verification switch in the configuration file; if the status of the verification switch is the open state, perform the step of obtaining the transaction attributes from the transaction request.

[0107] In some embodiments of the present application, the software testing apparatus further includes: a third forwarding module, configured to, if the status of the verification switch is the closed state, forward the transaction request to the second computing device.

[0108] In some embodiments of the present application, the transaction attribute obtaining module 620 includes: an obtaining unit, configured to obtain the value of the verification field from the transaction attribute verification conditions, where the value of the verification field is used to indicate the transaction attributes; an extraction unit, configured to extract the corresponding transaction attributes from the transaction request according to the value of the verification field.

[0109] In some embodiments of the present application, the software testing apparatus further includes: a processing result receiving module, configured to receive the processing result returned by the first computing device; a fourth forwarding module, configured to forward the processing result to an external system.

[0110] Figure 7 It is a schematic structural diagram of an electronic device shown according to an embodiment of the present application. The electronic device may be a server in a front-end system, and is configured to execute the software testing method provided by the present application.

[0111] As Figure 7 shown, the electronic device may include: a processor 701, such as a CPU, a network interface 704, a user interface 703, a memory 705, and a communication bus 702. Among them, the communication bus 702 is used to implement connection communication between these components. The user interface 703 may include a display screen (Display) and an input unit such as a keyboard (Keyboard). Optionally, the user interface 703 may further include a standard wired interface and a wireless interface. The network interface 704 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 705 may be a high-speed RAM memory, or may be a stable memory (non-volatile memory), such as a disk memory. The memory 705 may optionally be a storage device independent of the foregoing processor 701. It is worth mentioning that Figure 7The structure of the electronic device shown does not constitute a limitation on the electronic device, and it may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0112] As Figure 7 shown, the memory 705, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a program for implementing the software testing method.

[0113] In Figure 7 the electronic device shown, the network interface 704 is mainly used for communication connection with other devices, such as with Figure 1 an external system in , or with a first computing device in a post-system, a second computing device, etc. The user interface 703 is mainly used for connecting to a client (user side) and communicating data with the client; and the processor 701 can be used to call the program for implementing the software testing method stored in the memory 705 and execute the steps of the item delivery method in any of the above method embodiments.

[0114] According to one aspect of the embodiments of the present application, there is provided a computer-readable storage medium having computer-readable instructions stored thereon, which, when executed by a processor, implement the software testing method in any of the above method embodiments.

[0115] It should be noted that the computer-readable medium shown in the embodiments of the present application may be a computer-readable signal medium, a computer-readable storage medium, or any combination of the above two. A computer-readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program may be used by or in combination with an instruction execution system, apparatus, or device. In the present application, the computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may also be any computer-readable medium other than the computer-readable storage medium, and the computer-readable medium may send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted by any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0116] According to one aspect of the embodiments of the present application, there is provided a computer program product, which includes computer instructions that, when executed by a processor, implement the software testing method in any of the above method embodiments.

[0117] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In a flowchart or block diagram, each box may represent a module, a segment of a program, or a part of code, and the above-mentioned module, segment of a program, or part of code contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the boxes may occur in a different order than that marked in the accompanying drawings. For example, two consecutive boxes shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, as well as combinations of boxes in the block diagram or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0118] It should be noted that although several modules or units of devices for action execution are mentioned in the above detailed description, such a division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of the two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0119] Those skilled in the art will readily conceive of other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common general knowledge or conventional technical means in the technical field not disclosed in the present application.

[0120] It should be understood that the present application is not limited to the exact structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the present application is only limited by the appended claims.

Claims

1. A software testing method, characterized in that, Applied to a front-end system, the front-end system is communicatively connected to a back-end system. The back-end system includes a first computing device and a second computing device. The second computing device refers to other computing devices in the back-end system that have deployed the target software except the first computing device. The to-be-tested version of the target software is deployed on the first computing device, and the version of the target software deployed on the second computing device is lower than the to-be-tested version. A configuration file corresponding to the to-be-tested version of the target software is stored in the front-end system. The configuration file includes transaction attribute verification conditions configured for the to-be-tested version and the target network address of the first computing device. The method includes: Obtain a transaction request sent by an external system; Obtain transaction attributes from the transaction request; Match the transaction attributes with the transaction attribute verification conditions in the configuration file; If the transaction attributes in the transaction request match the transaction attribute verification conditions, forward the transaction request to the first computing device. The to-be-tested version of the target software deployed in the first computing device processes the transaction request, and determine the test result of the to-be-tested version according to the processing result of the to-be-tested version of the target software on the transaction request; If the transaction attributes in the transaction request do not match the transaction attribute verification conditions, forward the transaction request to the second computing device to process the transaction request through the target software deployed in the second computing device; Wherein, the obtaining transaction attributes from the transaction request includes: Obtain the value of a verification field from the transaction attribute verification conditions, and the value of the verification field is used to indicate transaction attributes; Extract the corresponding transaction attributes from the transaction request according to the value of the verification field; Wherein, the matching the transaction attributes with the transaction attribute verification conditions in the configuration file includes: Read the transaction attribute verification conditions from the loaded configuration file; Match the transaction attributes with the read transaction attribute verification conditions.

2. The method according to claim 1, characterized in that Before the matching the transaction attributes with the transaction attribute verification conditions in the configuration file, the method further includes: After the service in the front-end system is started, obtain the modification time of the configuration file in memory; If it is determined that the modification time of the configuration file in memory is different from the last modification time of the configuration file in the cache, load the configuration file in memory into the cache.

3. The method according to claim 2, wherein After the obtaining the modification time of the configuration file in memory after the service in the front-end system is started, the method further includes: If it is determined that the modification time of the configuration file in memory is the same as the last modification time of the configuration file in the cache, read the transaction attribute verification conditions from the configuration file in the cache; The matching the transaction attributes with the transaction attribute verification conditions in the configuration file includes: Match the transaction attributes with the transaction attribute verification conditions read from the cache.

4. The method according to claim 1, characterized in that, The method further includes: Determine the status of the verification switch in the configuration file; If the status of the verification switch is the open state, execute the step of obtaining the transaction attributes from the transaction request.

5. The method according to claim 4, wherein After determining the status of the verification switch in the configuration file, the method further includes: If the status of the verification switch is the closed state, forward the transaction request to the second computing device.

6. The method according to claim 1, characterized in that, After forwarding the transaction request to the first computing device, the method further includes: Receive the processing result returned by the first computing device; Forward the processing result to the external system.

7. A software testing device, characterized in that, Applied to a front-end system, the front-end system is communicatively connected to a back-end system, the back-end system includes a first computing device and a second computing device, the second computing device refers to other computing devices in the back-end system that have deployed the target software except the first computing device; the to-be-tested version of the target software is deployed on the first computing device, and the version of the target software deployed on the second computing device is lower than the to-be-tested version; a configuration file corresponding to the to-be-tested version of the target software is stored in the front-end system, the configuration file includes transaction attribute verification conditions configured for the to-be-tested version and the target network address of the first computing device, and the device includes: A transaction request acquisition module, configured to acquire a transaction request sent by an external system; A transaction attribute acquisition module, configured to acquire transaction attributes from the transaction request; A matching module, configured to match the transaction attributes with the transaction attribute verification conditions in the configuration file; A first forwarding module, configured to, if the transaction attributes in the transaction request match the transaction attribute verification conditions, forward the transaction request to the first computing device, and the to-be-tested version of the target software deployed in the first computing device processes the transaction request, and determine the test result of the to-be-tested version according to the processing result of the to-be-tested version of the target software for the transaction request; A second forwarding module, configured to, if the transaction attributes in the transaction request do not match the transaction attribute verification conditions, forward the transaction request to the second computing device to process the transaction request through the target software deployed in the second computing device; Wherein, the transaction attribute acquisition module is further configured to: Obtain the value of the verification field from the transaction attribute verification conditions, and the value of the verification field is used to indicate the transaction attributes; Extract the corresponding transaction attributes from the transaction request according to the value of the verification field; Wherein, the matching module is further configured to: Read the transaction attribute verification conditions from the loaded configuration file; Match the transaction attributes with the read transaction attribute verification conditions.

8. An electronic device, characterized in that, Includes: A processor; A memory, on which computer-readable instructions are stored, and when the computer-readable instructions are executed by the processor, the method according to any one of claims 1 to 6 is implemented.

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

Images