Test methods, devices, equipment, media and program products
By constructing transaction type test cases and time interval divisions for payment products for financial institutions, combined with automated verification rules, the problem of incomplete update testing of payment products is solved to ensure system stability and security.
Patent Information
- Application Number
- CN202210057122.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-01-18
- Publication Date
- 2025-09-05
- Estimated Expiration
- 2042-01-18
AI Technical Summary
During the update process of payment products of financial institutions, the test may be incomplete due to the failure of technicians to inform the update content or the update affects other functions, resulting in failure after going online.
By determining the transaction type of the object to be tested, a test case for each transaction type is constructed, a test transaction request is used to test the object to be tested, a time interval is divided for testing, and potential problems are automatically monitored and notified through verification rules.
It has achieved coverage testing of unknown update content and potential problems, timely discover and deal with possible product problems, and avoid failures after they go online.
Smart Images

Figure CN114416559B_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of information security or finance, and more specifically to a testing method, apparatus, device, medium, and program product. Background Art
[0002] Financial service providers, such as banks, require high security and stability for their products. For example, payment products process a massive number of transactions daily. Given the high volume of data required, any feature updates to payment products are typically tested and verified before release to ensure financial security and user experience.
[0003] Usually, technical personnel will inform testers of the specific update content, and testers will conduct targeted testing and verification of payment products based on their understanding of the known update content.
[0004] In the process of realizing the concept of the present disclosure, the inventors discovered the following problems in the related technology: if the technical staff misses the update content and fails to inform others, or if the update affects other functions, the problem may not be discovered in time due to the lack of comprehensive testing and verification, resulting in failure after the product is launched. Summary of the Invention
[0005] In view of the above problems, the present disclosure provides a testing method, apparatus, device, medium and program product capable of reducing missed tests.
[0006] One aspect of an embodiment of the present disclosure provides a testing method, including: determining an object to be tested, wherein the object to be tested is used to process transaction requests; obtaining N transaction types supported by the object to be tested, wherein the transaction type includes the type of the transaction request, and N is an integer greater than or equal to 1; obtaining a test transaction request based on M first test cases, wherein the first test case includes a case obtained according to at least one transaction function of each transaction type supported by the object to be tested, and M is an integer greater than or equal to 1; and testing the object to be tested using the test transaction request.
[0007] According to an embodiment of the present disclosure, the testing of the object to be tested using the test transaction request includes: dividing a preset time period into S time intervals, where S is an integer greater than or equal to 1; and testing the object to be tested in each of the S time intervals.
[0008] According to an embodiment of the present disclosure, testing is performed in I preset time periods, and each of the preset time periods is divided into S time intervals according to the same rule, where I is an integer greater than or equal to 2. The method further includes: obtaining a first test result of the i-th time interval in each of the preset time periods, where i is an integer greater than or equal to 1 and i is less than or equal to S; executing at least one verification rule based on the I first test results, where the I first test results correspond one-to-one to the i-th time interval in the I preset time periods; where the first test result corresponds to a first test case belonging to a first transaction type, and the first transaction type is any one of the N transaction types.
[0009] According to an embodiment of the present disclosure, executing at least one verification rule based on the I first test results includes: obtaining the number of failures in the I first test results, and the error information for each failure; executing the at least one verification rule based on the number of failures and / or the error information.
[0010] According to an embodiment of the present disclosure, the at least one verification rule includes at least one first verification rule, which is tested in the I+1th preset time period, and the S time intervals are divided within the I+1th preset time period. The method also includes: obtaining a second test result of the i-th time interval within the I+1th preset time period, wherein the second test result corresponds to the first test case; and executing the at least one first verification rule based on the second test result and I first test results.
[0011] According to an embodiment of the present disclosure, executing at least one first verification rule based on the second test result and I first test results includes: in the case that the second test result fails, determining the first error information of the second test result; determining the number of occurrences of the first error information in I first test results; obtaining the ratio of the number of occurrences to the number of failures in I first test results; and executing at least one first verification rule based on the ratio.
[0012] According to an embodiment of the present disclosure, obtaining the ratio of the number of occurrences to the number of failures includes: obtaining the ratio when the number of failures meets a preset condition.
[0013] According to an embodiment of the present disclosure, the method further includes: when the ratio matches any one of the at least one first verification rule, executing a first notification rule corresponding to the verification rule.
[0014] According to an embodiment of the present disclosure, it includes: when the second test result fails, adding 1 to the value of the number of failures, and then executing the at least one first verification rule.
[0015] According to an embodiment of the present disclosure, the method further includes: after adding 1 to the value of the number of failures, if any one of the at least one verification rule is matched, executing a second notification rule corresponding to the verification rule.
[0016] According to an embodiment of the present disclosure, the method further includes: acquiring updated content of the object to be tested; and constructing at least one second test case according to the updated content to test the object to be tested.
[0017] According to an embodiment of the present disclosure, it also includes: setting N test tasks in a one-to-one correspondence according to the N transaction types; associating each of the N test tasks with at least one test script, wherein each of the test scripts includes parameters of at least one first test case; wherein obtaining a test transaction request based on the M first test cases includes: executing the N test tasks to call at least one test script associated with each test task.
[0018] Another aspect of an embodiment of the present disclosure provides a testing device, including: an object determination module, used to determine an object to be tested, wherein the object to be tested is used to process transaction requests; a type acquisition module, used to obtain N transaction types supported by the object to be tested, wherein the transaction type includes the type of the transaction request, and N is an integer greater than or equal to 1; a request acquisition module, used to obtain a test transaction request based on M first test cases, wherein the first test case includes a case obtained according to at least one transaction function of each transaction type supported by the object to be tested, and M is an integer greater than or equal to 1; and an object testing module, used to test the object to be tested using the test transaction request.
[0019] Another aspect of an embodiment of the present disclosure provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the method described above.
[0020] Another aspect of the embodiments of the present disclosure further provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to execute the method described above.
[0021] Another aspect of the embodiments of the present disclosure further provides a computer program product, including a computer program, which implements the above method when executed by a processor.
[0022] One or more of the above-mentioned embodiments have the following beneficial effects: considering at least one transaction function of each transaction type, constructing a first test case corresponding to the test transaction function, which can enable testers to perform coverage testing on unknown update content or potential problems, and testing the test object through test transaction requests in a collision verification manner, and colliding with possible product problems, which can be dealt with in a timely manner to avoid failures after going online due to incomplete testing. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] The above contents and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:
[0024] Figure 1 The following schematically shows an application scenario diagram of the testing method according to an embodiment of the present disclosure;
[0025] Figure 2 The flowchart of the testing method according to the embodiment of the present disclosure is schematically shown;
[0026] Figure 3 Schematically shows a flow chart of a testing method according to another embodiment of the present disclosure;
[0027] Figure 4 A flowchart of testing an object to be tested according to an embodiment of the present disclosure is schematically shown;
[0028] Figure 5 Schematically shows a flow chart of a testing method according to another embodiment of the present disclosure;
[0029] Figure 6 Schematically shows a flow chart of a testing method according to another embodiment of the present disclosure;
[0030] Figure 7 A flowchart of executing at least one verification rule according to an embodiment of the present disclosure is schematically shown;
[0031] Figure 8 Schematically illustrates a flow chart for executing at least one first verification rule according to another embodiment of the present disclosure;
[0032] Figure 9 Schematically illustrates a flow chart for executing at least one first verification rule according to another embodiment of the present disclosure;
[0033] Figure 10 Schematically shows a structural block diagram of a testing device according to an embodiment of the present disclosure;
[0034] Figure 11Schematically shows a structural block diagram of a testing device according to another embodiment of the present disclosure;
[0035] Figure 12 The block diagram schematically shows an electronic device suitable for implementing the testing method according to an embodiment of the present disclosure. DETAILED DESCRIPTION
[0036] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present disclosure. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.
[0037] Taking quick payment products as an example, with the rapid development of internet finance, banks are collaborating increasingly closely with various third-party institutions, particularly across a wide range of payment scenarios, to provide customers with a convenient and secure payment experience. Third-party quick payment products are foundational payment products used by payment institutions and card issuers to develop payment scenarios. Transactions based on these products typically reach hundreds of millions of transactions per day. This high transaction volume places extremely high demands on system stability.
[0038] In terms of testing, existing testing and verification processes are based on an understanding of known update content before conducting testing. However, organizational and communication issues can lead to omissions in notifying testers of some system upgrades and modifications. Alternatively, a feature update can disrupt the proper functioning of other product functions. This can result in some updates or hidden issues being released into production without verification and testing. For transactions involving large transaction volumes and accounting processing, this can easily lead to serious production safety incidents, sparking numerous customer complaints, and sparking public outcry.
[0039] Embodiments of the present disclosure provide a testing method. The method includes: determining a test object, wherein the test object is configured to process transaction requests; obtaining N transaction types supported by the test object, wherein a transaction type includes a transaction request type, and N is an integer greater than or equal to 1; obtaining a test transaction request based on M first test cases, wherein the first test case includes a case obtained based on at least one transaction function for each transaction type supported by the test object, and M is an integer greater than or equal to 1; and testing the test object using the test transaction request.
[0040] It should be noted that the objects to be tested are not limited to payment products, but can also be used for other products capable of transaction processing provided by financial institutions such as banks, insurance, securities, etc. that provide financial services, or by third-party institutions that cooperate with financial institutions.
[0041] According to the embodiments of the present disclosure, at least one transaction function for each transaction type is considered, and a first test case corresponding to the test transaction function is constructed. This allows testers to conduct comprehensive testing of unknown updates or potential issues. Using a collision verification approach, the test object is tested using test transaction requests, identifying potential product issues and addressing them promptly, thus avoiding post-launch failures due to incomplete testing.
[0042] It should be noted that the testing methods, devices, equipment, media and program products provided in the embodiments of the present disclosure can be used for product testing in the financial field, and can also be used in any field other than the financial field. The application fields of the testing methods, devices, equipment, media and program products provided in the embodiments of the present disclosure are not limited.
[0043] Figure 1 The following schematically illustrates an application scenario diagram of the testing method according to an embodiment of the present disclosure.
[0044] like Figure 1 As shown, the application scenario 100 according to this embodiment may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium for providing a communication link between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or optical fiber cables.
[0045] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).
[0046] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.
[0047] The server 105 may be a server that provides various services, such as a background management server (for example only) that supports websites browsed by users using the terminal devices 101, 102, and 103. The background management server may analyze and process received data such as user requests, and feed back processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device.
[0048] It should be noted that the test method provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the test device provided in the embodiment of the present disclosure can generally be set in the server 105. The test method provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Accordingly, the test device provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105.
[0049] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.
[0050] The following will be based on Figure 1 The scene described by Figures 2 to 9 The testing method of the embodiment of the present disclosure is described in detail.
[0051] Figure 2 The flowchart of the testing method according to the embodiment of the present disclosure is schematically shown.
[0052] like Figure 2 As shown, the testing method of this embodiment includes operations S210 to S240.
[0053] In operation S210 , an object to be tested is determined, where the object to be tested is used to process a transaction request.
[0054] The object to be tested may include a product or system that has been updated. For example, a specific payment product can be identified through the update log generated by the technician.
[0055] In operation S220 , N transaction types supported by the object to be tested are obtained, where the transaction type includes the type of transaction request, and N is an integer greater than or equal to 1.
[0056] Transaction types include, for example, payment, refund, repayment, transfer or loan (for example only). Transaction requests include requests issued by users to handle various types of services. The type of transaction request can be determined based on the service type, such as payment service, refund service, repayment service, transfer service or loan service.
[0057] In operation S230 , a test transaction request is obtained based on M first test cases, where the first test cases include cases obtained according to at least one transaction function of each transaction type supported by the object to be tested, and M is an integer greater than or equal to 1.
[0058] The first test case can be constructed based on the transaction type, transaction function, transaction scenario and test parameters. For example, for the limit function in the payment type, in a large-value transaction scenario, parameters of different amounts can be set to construct a corresponding test case for the limit function in the payment type.
[0059] The M first test cases can be constructed based on frequently encountered production issues, the primary transaction functions of the testee, or even each transaction function within all transaction types. Their purpose is to comprehensively cover transaction functions, simulate various business requirements that may arise in the production environment, and identify potential product issues for timely resolution.
[0060] In operation S240 , the test object is tested using the test transaction request.
[0061] For example, for quick payment products, a payment script can be executed to issue a test transaction request. The quick payment product then processes the test transaction request and outputs the transaction result. The payment script includes case parameters constructed based on the transaction type, transaction function, transaction scenario, and test parameters.
[0062] According to the embodiments of the present disclosure, at least one transaction function of each transaction type is taken into consideration, and a first test case corresponding to the test transaction function is constructed. This allows testers to perform coverage testing on unknown update content, and to test the test object through test transaction requests in a collision verification manner, so as to identify possible product problems and deal with them in a timely manner, thereby avoiding transaction processing failures caused by incomplete testing after going online.
[0063] Figure 3 The flowchart of a testing method according to another embodiment of the present disclosure is schematically shown.
[0064] The testing method of this embodiment may include operations S210 to S240. Figure 3 As shown, operations S310 to S320 may also be included.
[0065] In operation S310 , updated content of the object to be tested is obtained.
[0066] In operation S320 , at least one second test case is constructed according to the updated content to test the object to be tested.
[0067] Updates can include detailed information, such as updates to the currency functionality of the payment types supported by the Quick Payment product to enable it to handle more fiat currencies. Therefore, a second test case can be constructed specifically to test the currency functionality of the payment type, for example, with parameters that include the newly added currency.
[0068] According to the embodiments of the present disclosure, the second test case can make the testing process more targeted, allowing for quick feedback to technicians and enabling them to address any issues. Furthermore, the first test case can include the second test case, thereby achieving a comprehensive test effect. The first test case can also exclude the second test case to avoid duplication of test content. In this case, the second test case serves as a targeted functional test, while the first test case serves to identify potential problems.
[0069] Figure 4 The flowchart of testing the object to be tested in operation S240 according to an embodiment of the present disclosure is schematically shown.
[0070] like Figure 4 As shown, testing the object to be tested using the test transaction request in operation S240 may include operations S410 to S420.
[0071] In operation S410 , a preset time period is divided into S time intervals, where S is an integer greater than or equal to 1.
[0072] According to an embodiment of the present disclosure, the preset time period may include 24 hours within a day (for example only). The time interval may be a 0.5 hour interval. The preset time period may be divided into 0.5 hour intervals starting from midnight.
[0073] In operation S420 , the object to be tested is tested in each of the S time intervals.
[0074] Exemplarily, the test object may be tested once every 0.5 hours according to the M first test cases.
[0075] According to the embodiments of the present disclosure, on the one hand, a comprehensive coverage test is conducted on different transaction scenarios (such as debit cards, credit cards, third-party transaction institutions, etc.) from the perspective of transaction type and transaction function through M first test cases. On the other hand, considering that different time intervals may result in different numbers of transactions processed, or that the object to be tested may have different operation and maintenance methods in different time intervals, a comprehensive coverage test is conducted on the object to be tested from the dimension of time.
[0076] Figure 5 The flowchart of a testing method according to another embodiment of the present disclosure is schematically shown.
[0077] like Figure 5 As shown, the testing method of this embodiment includes operations S510 to S530, wherein obtaining a test transaction request based on M first test cases includes operation S530.
[0078] In operation S510 , N test tasks are set in a one-to-one correspondence according to the N transaction types.
[0079] Each test task may include the start time and end time of the task cycle, as well as the task cycle frequency. It can be flexibly set according to S time intervals. Table 1 schematically shows the test task content according to an embodiment of the present disclosure.
[0080] Table 1
[0081]
[0082] In operation S520 , each of the N test tasks is associated with at least one test script, wherein each test script includes at least one parameter of a first test case.
[0083] As shown in Table 1, Task 1 is associated with Payment Script-Credit Card and Payment Script-Debit Card. The parameters of each first test case may include transaction type, transaction function, transaction scenario, and specific transaction parameters (ie, the above-mentioned test parameters).
[0084] In operation S530 , N types of test tasks are executed to call and execute at least one test script associated with each test task.
[0085] By executing each test script, a corresponding test transaction request is generated, so that the object to be tested processes the test transaction request and completes the test process.
[0086] According to the embodiments of the present disclosure, test scripts are associated with test tasks, and each test script corresponds to a dimension of a test case, which can achieve flexible management during the test process and realize comprehensive testing as much as possible.
[0087] Figure 6 The flowchart of a testing method according to another embodiment of the present disclosure is schematically shown.
[0088] The testing method of this embodiment includes operations S410 to S420. Figure 6 As shown, the method further includes operations S610 to S620. The test is performed in I preset time periods, and each preset time period is divided into S time intervals according to the same rule, where I is an integer greater than or equal to 2.
[0089] In operation S610 , a first test result of the i-th time interval in each preset time period is obtained, where i is an integer greater than or equal to 1 and i is less than or equal to S.
[0090] The first test result corresponds to a first test case belonging to a first transaction type, the first transaction type is any one of N transaction types, and the i-th time interval can be any one of S time intervals.
[0091] In an optional implementation, transaction type is used as the acquisition granularity, where the first test result includes the transaction results of all test cases under the first transaction type. For example, each test case corresponds to a test transaction request, and the first test result includes at least one transaction result output by the test subject for all test transaction requests of the first transaction type.
[0092] Another optional implementation is to use each transaction as the acquisition granularity. Here, each transaction corresponds to a first test case. The first test result can be the transaction result of any test case under the first transaction type.
[0093] Let's take each transaction as an example of the acquisition granularity. For example, if the value of I is 5, the test analysis is based on the first test result of the first five days. Within each day, the time interval can be divided into intervals starting from midnight according to the rule of every 0.5 hours. Taking the repayment type as an example, the first test result of a case of the repayment type is obtained between 8:00 and 8:30 every day. For example, if there are 10 test cases corresponding to the repayment type (for example only), 10 test transaction requests will be obtained to form 10 transactions. The first test result can be the transaction result corresponding to any of the 10 test cases.
[0094] In operation S620, at least one verification rule is executed according to I first test results, wherein the I first test results correspond one-to-one to an i-th time interval within I preset time periods.
[0095] At least one verification rule can verify the first test result from different dimensions and horizontal angles. The different dimensions can be that each verification rule has a specific judgment condition, and if the judgment condition is met, it serves as one of the bases for whether the test passes.
[0096] For example, a horizontal comparison involves comparing the first test results between 8:00 AM and 8:30 AM daily for five days. Because the test subjects experience similar scenarios during the same time period each day, such as similar transaction volumes and operating environments, potential issues can be identified in each time period.
[0097] In other embodiments, the test analysis may be performed from a vertical perspective, where the vertical perspective refers to analyzing the first test result of each of S time intervals within a preset time period.
[0098] For example, within a single day, the number of transactions processed varies across different time periods. Furthermore, different operational methods may be employed at different times. For example, updating the time of a test object at midnight could cause a significant discrepancy between the time of the transaction request and the time of the test object, leading to issues such as request timeouts and failure to successfully process the test object.
[0099] For the same transaction type, through the S first test results of S time intervals, the interval with more transaction failures within the same preset time period can be determined from a vertical perspective, and the relevant operations and parameters of the interval can be promptly checked and processed in a targeted manner.
[0100] In some embodiments, both vertical and horizontal angles can be considered to improve the accuracy of troubleshooting. For example, if the highest number of transaction failures occurs between 8:00 and 8:30 on the first day, while no transaction failures occur in this interval during other preset time periods, this may be caused by factors such as network problems or hardware issues, rather than defects in the object being inspected.
[0101] It should be noted that the testing method provided by the embodiments of the present disclosure can be implemented regardless of whether the first test result is obtained at the granularity of each transaction or at the granularity of transaction type. For example, if the repayment type corresponds to 10 test cases, when the granularity is transaction type, the first test result can include all 10 transaction results. Regardless of the number of transaction results included in the first test result, it does not affect the number of failed transaction results or the statistics of the error message for each failure.
[0102] The following is an example of testing and analyzing from a horizontal perspective, taking each transaction as the acquisition granularity. Figure 7 Further details are given.
[0103] Figure 7 The flowchart of executing at least one verification rule in operation S620 according to an embodiment of the present disclosure is schematically shown.
[0104] like Figure 7 As shown, in operation S620, executing at least one verification rule according to I first test results includes operations S710 to S720.
[0105] In operation S710, the number of failures in the first test results and error information for each failure are obtained.
[0106] According to an embodiment of the present disclosure, the first test case A in the repayment type can be: repaying $100 using a debit card through the mobile app of third-party institution A. When i is 5, the first test result for first test case A, i.e., the transaction result for first test case A, is obtained from the i-th time interval of each day. This result can include either a success or a failure. In the case of a failure, the tested object can return an error message. For example, of the five transaction results for first test case A, three failed and two succeeded. Therefore, the number of failures is 3.
[0107] In operation S720 , at least one verification rule is executed according to the number of failures and / or the error information.
[0108] According to an embodiment of the present disclosure, at least one verification rule may include at least one second verification rule, the function of which is to perform test analysis based on the first test result within I preset time period.
[0109] For example, a comparison result of the number of failures and a preset number of times is obtained to determine whether the second verification rule is matched. And / or a comparison result of the number of occurrences of a particular error message in the error message and the number of failures is obtained to determine whether the second verification rule is matched. For example, if the preset number of times is 4 and the number of failures is 3, the second verification rule may be matched, and no further investigation is performed, as the preset number of times has not been exceeded.
[0110] According to the embodiments of the present disclosure, the number of failures is obtained and verified using verification rules, enabling automated monitoring of test status. For example, during the execution of a test task by executing an automated script, if the number of failures or error information matches a verification rule, it may indicate a potential problem, and relevant personnel can be promptly alerted, saving the cost of manual monitoring.
[0111] Figure 8 A flowchart for executing at least one first verification rule according to another embodiment of the present disclosure is schematically shown.
[0112] The at least one verification rule may further include at least one first verification rule, wherein the test is performed in the I+1th preset time period, and the I+1th preset time period is divided into S time intervals. The test method of this embodiment, based on operations S610 to S620, is as follows: Figure 8 As shown, operations S810 to S820 may also be included.
[0113] In operation S810 , a second test result of an i-th time interval within an (I+1)-th preset time period is obtained, where the second test result corresponds to the first test case.
[0114] In operation S820, at least one first verification rule is executed according to the second test result and the I first test results.
[0115] According to an embodiment of the present disclosure, one first test result is used as a control to determine whether the second test result is an abnormal situation, so as to adopt a targeted processing method.
[0116] Table 2 schematically shows at least one first verification rule of an embodiment of the present disclosure, as shown below.
[0117] Table 2
[0118]
[0119] Refer to Table 2, by configuring different parameters, you can monitor the test results in the i-th time interval within the I+1 preset time period. The "Interval Name" column can be configured with a specific time interval, and the "Safety Interval Content" column can be configured with specific test result acquisition rules. The "First Verification Rule" column can be configured with specific verification rules. The "I", "Q", and "O" columns can be configured with specific values for I, O, and Q, respectively. The "Q" column can be left blank.
[0120] For example, if the test task begins on August 1, XX (for example only), and the (I+1) preset time period is August 4, XX, then I can be set to 3. As shown in Table 2, the time interval is 6:30-7:00 AM. The "Second test result for the current interval of transaction type O" in the safety interval content is the transaction result of the first test case for transaction type 1001 (e.g., payment type) between 6:30 AM and 7:00 AM on August 4. The "Together with the first test result for the same interval in the past I days" in the safety interval content refers to the transaction results for the same transaction and interval from August 1 to August 3.
[0121] According to an embodiment of the present disclosure, when the second test result fails, the value of the number of failures is incremented by 1, and then at least one first verification rule is executed.
[0122] Referring to Table 2, the cardinality for the three validation rules, "Q failures within I+1 days, Q = 0," "At least Q failures within I+1 days, Q < I+1," and "Q failures within I+1 days, Q = I+1," is I+1. This means it monitors the number of failures within a four-day period. For example, from 6:30 AM to 7:00 AM on August 1st to August 3rd, the first test case A is executed three times, resulting in two failures. If the first test case A fails between 6:30 AM and 7:00 AM on August 4th, the number of failures increases by 1 to 3, giving a cardinality of 4.
[0123] Optionally, the "Q" column in Table 2 can be empty. If the number of failures is obtained plus 1 to get 3, Q is assigned a value of 3. Then, the judgment is performed in sequence: "Q failures occur, Q = 0", "at least Q failures occur, Q < I + 1", and "Q failures occur, Q = I + 1".
[0124] Optionally, the "Q" column in Table 2 can be predefined. Taking "at least Q failures occur, Q < I + 1" as an example, if I is 5, the cardinality I + 1 is 6. The value of Q can be predefined to be 5. If there are 4 failures in 6 days, the verification rule will not be matched because the condition of at least 5 failures is not met. In this case, "Q < I + 1" can still be executed. Its role is that if the value of Q is predefined to be 7, but the maximum number of times is 6, the failure of the verification rule can be detected in time.
[0125] Figure 9 A flowchart of executing at least one first verification rule in operation S820 according to another embodiment of the present disclosure is schematically shown.
[0126] like Figure 9 As shown, in operation S820, executing at least one first verification rule according to the second test result and I first test results may include operations S910 to S940.
[0127] In operation S910 , if the second test result fails, first error information of the second test result is determined.
[0128] For example, the transaction result of the first test case A between 6:30 and 7:00 on August 4 (i.e., the (I+1) preset time period) was a failure, and the error reason was that the currency was not supported (i.e., the first error message).
[0129] In operation S920, the number of occurrences of the first error information in the I first test results is determined.
[0130] In operation S930, a ratio of the number of occurrences to the number of failures in the I first test results is obtained.
[0131] Table 3 schematically shows I first test results and second test results in some embodiments of the present disclosure, as shown below.
[0132] Table 3
[0133] Preset time period Time interval Transaction Results Error reason August 1 6:30~7:00 success none August 2 6:30~7:00 fail Network Error August 3 6:30~7:00 fail Unsupported currency August 4 6:30~7:00 fail Unsupported currency
[0134] Refer to Table 3. In the past three days, there have been two failed transactions, along with the corresponding error reasons (i.e., error messages). "Unsupported Currency" appeared once in the error message in the past three days. Therefore, with two failures and one occurrence, the ratio is 50%.
[0135] According to an embodiment of the present disclosure, in operation S930, it can be determined whether the number of failures meets the preset conditions, and when the number of failures meets the preset conditions, the ratio is obtained. Figure 2 For example, in the verification percentage rule, if the preset value of Q is 3, the verification rules are: "There have been at least Q failures in the past day, and the current error cause accounts for greater than or equal to 50% of the failures in the past day", "There have been at least Q failures in the past day, and the current error cause accounts for less than 50% but greater than 0% of the failures in the past day", and "There have been at least Q failures in the past day, and the current error cause accounts for 0% of the failures in the past day". If a first test result shows two failures as shown in Table 3, it does not match any verification rule.
[0136] In operation S940 , at least one first verification rule is executed according to the ratio.
[0137] Referring to Table 2, when the ratio is 50%, the following three verification rules can be executed: "The current error cause accounts for greater than or equal to 50% of the number of failures in the past 1 day", "The current error cause accounts for less than 50% and greater than 0 of the number of failures in the past 1 day", and "The current error cause accounts for 0 of the number of failures in the past 1 day".
[0138] Taking the verification rule "the current error cause accounts for 0 of the failure times in the past 1 day" as an example, if August 1 to August 3 are all successful, then the current error cause accounts for 0 of the failure times in the past 1 day.
[0139] According to an embodiment of the present disclosure, when the second test result is a failure, the first error message is used as a monitoring indicator to analyze whether the indicator matches a first verification rule within a preset time period. This determines how to handle the occurrence of the first error message in the (I+1)th preset time period, thereby achieving flexible, accurate, and multi-dimensional monitoring effects.
[0140] Table 4 schematically shows I first test results and second test results in some embodiments of the present disclosure, as shown below.
[0141] Table 4
[0142]
[0143] Reference Figure 2 , multiple verification rules are configured based on two dimensions: the number of failures and the specific error reason ratio. Figure 4 In the example, it can match "Q failures occurred within I+1 days, where Q = I+1" and "the current error cause accounts for 0 of the failures in the past I days." Combined with the validation rule for the number of failures, this can prevent the situation where the current error cause accounts for 0 of the failures in the past I days and you fail to investigate, potentially overlooking potential issues.
[0144] According to an embodiment of the present disclosure, if the ratio matches any one of the at least one first verification rule, the first notification rule corresponding to the verification rule is executed. Alternatively, after incrementing the number of failures by 1, if the ratio matches any one of the at least one first verification rule, the second notification rule corresponding to the verification rule is executed.
[0145] Table 5 schematically shows the content of notification rules in some embodiments of the present disclosure, as shown below.
[0146] Table 5
[0147]
[0148] Reference Figure 4 You can configure a corresponding notification rule (including the first notification rule or the second notification rule) for each verification rule. A notification rule can include a contact, notification method, notification address, and attention level. When executing a corresponding notification rule, you can call the corresponding notification interface according to the notification method, and send information such as the attention level and verification rule to the contact according to the notification address.
[0149] According to the embodiments of the present disclosure, automated traceability and notification of transaction results are achieved, and a dynamic safety interval within the test cycle is formed based on each transaction. Contacts can be automatically notified, thereby improving the accuracy and efficiency of test problem troubleshooting.
[0150] It should be noted that the configuration contents in Table 2 and Table 5 are only examples and can be flexibly configured according to actual conditions, and this disclosure does not limit them.
[0151] Based on the above test method, the present disclosure also provides a test device. Figure 10 and Figure 11The device is described in detail.
[0152] Figure 10 The figure schematically shows a structural block diagram of a testing device 1000 according to an embodiment of the present disclosure.
[0153] like Figure 10 As shown, the testing device 1000 of this embodiment includes an object determination module 1010 , a type acquisition module 1020 , a request acquisition module 1030 and an object testing module 1040 .
[0154] The object determination module 1010 may perform operation S210 to determine an object to be tested, where the object to be tested is used to process a transaction request.
[0155] The type acquisition module 1020 may perform operation S220 to acquire N transaction types supported by the object to be tested, where the transaction type includes a type of transaction request, and N is an integer greater than or equal to 1.
[0156] The request acquisition module 1030 may perform operation S230 to obtain a test transaction request based on M first test cases, wherein the first test cases include cases obtained according to at least one transaction function of each transaction type supported by the object to be tested, and M is an integer greater than or equal to 1.
[0157] The object testing module 1040 may perform operation S240 to test the object to be tested using the test transaction request.
[0158] The object testing module 1040 may perform operations S410 to S420 , operations S610 to S620 , operations S710 to S720 , operations S810 to S820 , and operations S910 to S940 , which are not described in detail herein.
[0159] The testing device 1000 may further include a targeted testing module, which may be used to perform operations S310 to S320 , and will not be described in detail herein.
[0160] The testing device 1000 may further include a script module, and the script module is used to execute operations S510 to S520 , which will not be described in detail here.
[0161] It should be noted that the implementation methods, technical problems solved, functions implemented, and technical effects achieved of each module / unit / sub-unit in the device part embodiment are the same or similar to the implementation methods, technical problems solved, functions implemented, and technical effects achieved of each corresponding step in the method part embodiment, and will not be repeated here.
[0162] Figure 11The figure schematically shows a structural block diagram of a testing device 1100 according to another embodiment of the present disclosure.
[0163] like Figure 11 As shown, the testing device 1100 may include a script maintenance module 1110 , an execution module 1120 , a notification module 1130 , a parameter module 1140 , an information storage module 1150 , and a dynamic safety interval module 1160 .
[0164] The script maintenance module 1110 is used by testers to design and compile automated test scripts for collision verification based on transactions. After the script is compiled, the information is stored in the information storage module 1150.
[0165] The operation module 1120 can be combined with the test device 1100 to execute Figures 2 to 9 The execution module 1120 schedules the automated script periodically based on the task information set in the parameter module 1140. The task information set in the parameter module 1140 includes the task cycle start and end times, the task cycle frequency, and the corresponding task script. After the script execution is completed, the transaction execution information is stored in the information storage module 1150 and sent to the dynamic safety interval module 1160. Based on the response information from the dynamic safety interval module 1160, the notification module 1130 is called and the information is stored in the information storage module 1150.
[0166] The notification module 1130 is used to receive the transaction information sent by the operation module 1120 after the execution of the operation module 1120 is completed, and select the corresponding notification method based on the notification information maintained by the parameter module 1140 stored in the information storage module 1150, and notify the execution result information to the best relevant personnel.
[0167] The parameter module 1140 is used to maintain the script, cycle information, and whether to enable the dynamic safety zone of the execution of the maintenance task. After the maintenance is completed, the maintenance result is sent to the information storage module 1150.
[0168] The information storage module 1150 is used to store the parameter information maintained by the parameter module 1140, the script information stored in the script maintenance module 1110, the transaction information executed by the operation module 1120, and the dynamic security interval information stored by the dynamic security interval module 1160, including but not limited to the transaction type, the corresponding contact person and notification method after hitting different security intervals, and the verification rules.
[0169] The dynamic security interval module 1160 is used to maintain verification rules, transaction types, and notification methods and contacts after matching different verification rules.
[0170] The script maintenance module 1110 may include a script basic information maintenance unit, a script configuration unit, and a script sending unit. The script basic information maintenance unit is used to maintain basic script information, including but not limited to basic script parameters such as test card data and test amount. The script configuration unit is used by testers to create corresponding automation scripts based on test cases. The script sending unit sends the created automation scripts to the information storage module 1150 for storage.
[0171] The operation module 1120 may include a monitoring unit, an operation information acquisition unit, an operation scheduling unit, an operation information receiving unit, and an operation information sending unit.
[0172] The monitoring unit is a unit used to monitor whether the task command pushed by the parameter module is received, and monitor the execution status of the currently running task.
[0173] When the monitoring unit receives the task, it pushes the task information to the operation information acquisition unit. The operation information acquisition unit obtains the task information from the information storage module according to the task information pushed by the monitoring unit, and pushes the task information to the operation scheduling unit.
[0174] The execution scheduling unit is used to receive the task information obtained by the execution information acquisition unit, obtain the corresponding script information from the information storage module based on the information, schedule the script execution, and send the execution result information to the operation information sending unit. If dynamic safety intervals are used, the execution result information is also sent to the dynamic safety interval module 1160.
[0175] The operation information receiving unit is used to receive the response result of the dynamic safety interval module 1160 and synchronously send the response information to the operation information sending unit.
[0176] The operation information sending unit is used to send the execution result information pushed by the operation scheduling unit to the information storage module, and at the same time send it to the information storage module 1150 according to the information pushed by the operation information receiving unit, and call the notification module 1130 to notify the contact person.
[0177] Notification module 1130 may include a notification information receiving unit, a notification method selection unit, and a notification information sending unit. The notification information receiving unit is configured to receive the notification information pushed by the operation information sending unit and, based on the notification method in the information, push the information to the notification method selection unit. The notification method selection unit is configured to receive the notification method pushed by the notification information receiving unit and, based on the notification method, select the corresponding sending method to send the information. The notification information sending unit then simultaneously pushes the information to the notification information sending unit. The notification information sending unit is a unit that sends the information sending results to the information storage module 1150 for storage.
[0178] The parameter module 1140 may include a task information maintenance unit and a task pushing unit.
[0179] The task information maintenance unit is used by testers to maintain task information. As shown in Table 1, for example, a task maintained by a tester allows for flexible maintenance of payment transaction types. From 6:30 AM on August 1, 2021, to 7:00 AM on August 7, 2021, the Payment Script - Credit Card and Payment Script - Debit Card scripts were automatically executed every 0.5 hours to perform collision verification against unknown modifications. Both scripts associated with the current task have the dynamic safety interval feature enabled.
[0180] The task association unit is used to associate tasks with transaction types, scenario types, and corresponding automation scripts. The task push unit is used to push the maintained task information to the information storage module 1150 for storage and, when the task start time is triggered, push it to the monitoring unit of the operation information module.
[0181] The information storage module 1150 may include a script storage unit, a parameter information storage unit, an operation information storage unit, a notification information storage unit, and a dynamic security zone information storage unit.
[0182] The script storage unit is used to store the automation scripts pushed by the script sending unit. The parameter information storage unit is used to store the task information pushed by the information pushing unit. The operation information storage unit is used to store the transaction execution result information pushed by the operation information sending unit. The notification information storage unit is used to store the sending information results pushed by the notification information sending unit. The dynamic security interval information storage unit is used to store the dynamic security interval related information pushed by the dynamic security interval information maintenance unit.
[0183] The dynamic security interval module 1160 may include a dynamic security interval information receiving unit, a dynamic security interval information maintaining unit, a dynamic security interval operating unit, and a dynamic security interval sending unit.
[0184] The dynamic safety interval information receiving unit is used to receive the operation result information pushed by the operation scheduling unit, and push the operation result information to the dynamic safety interval operation unit to execute the verification rules.
[0185] The dynamic security zone information maintenance unit is used to maintain verification rules, contacts and contact information pushed in different situations of hitting the dynamic security zone, and push the maintenance information to the dynamic security zone information storage unit.
[0186] The dynamic safety interval operation unit is used to receive the operation result information pushed by the dynamic safety interval information receiving unit, perform calculations according to the verification rules maintained by the dynamic safety interval information maintenance unit, and push the calculation results to the dynamic safety interval sending unit.
[0187] The dynamic security interval sending unit is used to receive the calculation results pushed by the dynamic security interval operation unit, including but not limited to which security interval is hit and the corresponding contact person, and push the information to the operation information receiving unit after receiving it.
[0188] The testing device 1100 according to the embodiment of the present disclosure enables testers to flexibly conduct automated collision testing of different transactions. This effectively targets transactions with unknown update content, and allows for automated tracking and notification of transaction results. Collision verification, as described herein, involves the automated execution of transaction-covered functions to address potential missed modifications, thereby improving the overall quality of the testing process. Furthermore, a dynamic safety interval within the testing cycle is established based on transactions, enabling automated preliminary identification and troubleshooting of transaction results and automatic notification of the optimal person to address the current issue, thereby improving the accuracy and efficiency of test problem troubleshooting.
[0189] According to an embodiment of the present disclosure, any multiple modules in the test device 1000 or the test device 1100 can be combined into a single module, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of the modules can be combined with at least part of the functionality of other modules and implemented in a single module.
[0190] According to an embodiment of the present disclosure, at least one module in the test device 1000 or the test device 1100 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or may be implemented by hardware or firmware in any other reasonable manner of integrating or packaging a circuit, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in an appropriate combination of any of them. Alternatively, at least one module in the test device 1000 or the test device 1100 may be at least partially implemented as a computer program module, which may perform corresponding functions when executed.
[0191] Figure 12 The block diagram schematically shows an electronic device suitable for implementing the testing method according to an embodiment of the present disclosure.
[0192] like Figure 12As shown, the electronic device 1200 according to an embodiment of the present disclosure includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1202 or a program loaded from a storage part 1208 into a random access memory (RAM) 1203. The processor 1201 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a dedicated microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1201 may also include an onboard memory for caching purposes. The processor 1201 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.
[0193] Various programs and data required for the operation of the electronic device 1200 are stored in the RAM 1203. The processor 1201, the ROM 1202, and the RAM 1203 are connected to each other via a bus 1204. The processor 1201 performs various operations of the method flow according to the embodiment of the present disclosure by executing the programs in the ROM 1202 and / or the RAM 1203. It should be noted that the programs may also be stored in one or more memories other than the ROM 1202 and the RAM 1203. The processor 1201 may also perform various operations of the method flow according to the embodiment of the present disclosure by executing the programs stored in the one or more memories.
[0194] According to an embodiment of the present disclosure, electronic device 1200 may further include an input / output (I / O) interface 1205, which is also connected to bus 1204. Electronic device 1200 may further include one or more of the following components connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 1208 including a hard disk; and a communication section 1209 including a network interface card such as a LAN card or a modem. Communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in drive 1210 as needed, so that computer programs read from the removable media can be installed into storage section 1208 as needed.
[0195] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently and not be incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, and when executed, implements the method according to the embodiments of the present disclosure.
[0196] According to an embodiment of the present disclosure, a computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present disclosure, a computer-readable storage medium may include the ROM 1202 and / or RAM 1203 described above and / or one or more memories other than ROM 1202 and RAM 1203.
[0197] The embodiments of the present disclosure also include a computer program product, which includes a computer program containing program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the method provided by the embodiments of the present disclosure.
[0198] The computer program executes the above functions defined in the system / device of the embodiment of the present disclosure when the processor 1201 executes the computer program. According to the embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by a computer program module.
[0199] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal on a network medium, downloaded and installed via the communication portion 1209, and / or installed from the removable medium 1211. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.
[0200] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1209 and / or installed from the removable medium 1211. When the computer program is executed by the processor 1201, the above-described functions defined in the system of the embodiment of the present disclosure are performed. According to the embodiment of the present disclosure, the systems, devices, means, modules, units, etc. described above can be implemented by computer program modules.
[0201] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, languages such as Java, C++, python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).
[0202] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0203] The embodiments of the present disclosure are described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be used in combination to advantage. The scope of the present disclosure is defined by the appended claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make various substitutions and modifications, which should all fall within the scope of the present disclosure.
Claims
1. A testing method comprising: Determining an object to be tested, wherein the object to be tested is used to process a transaction request; Obtaining N transaction types supported by the object to be tested, wherein the transaction type includes the type of the transaction request, and N is an integer greater than or equal to 1; Obtaining a test transaction request based on M first test cases, wherein the first test cases include cases obtained according to at least one transaction function of each transaction type supported by the object to be tested, and M is an integer greater than or equal to 1; Testing the object to be tested using the test transaction request; The step of testing the object to be tested by using the test transaction request includes: Divide the preset time period into S time intervals, where S is an integer greater than or equal to 1; Testing the object to be tested in each time interval of the S time intervals; The test is performed in I preset time periods, and each of the preset time periods is divided into S time intervals according to the same rule, where I is an integer greater than or equal to 2, including: Obtaining a first test result of the i-th time interval within each of the preset time periods, where i is an integer greater than or equal to 1 and i is less than or equal to S; executing at least one verification rule according to the first test results, wherein the first test results correspond one-to-one to an i-th time interval within the preset time period; The first test result corresponds to a first test case belonging to a first transaction type, where the first transaction type is any one of the N transaction types; the at least one verification rule includes at least one first verification rule, and the test is performed in the (I+1)th preset time period, where the (I+1)th preset time period is divided into the S time intervals, including: Obtaining a second test result of an i-th time interval within the (I+1)-th preset time period, wherein the second test result corresponds to the first test case; According to the second test result and I first test results, execute the at least one first verification rule, wherein the at least one first verification rule is configured according to the preset time period number and the number of failures.
2. The method according to claim 1, wherein The executing at least one verification rule according to the first test result includes: Obtain the number of failures in the first test result and the error message for each failure; Execute the at least one verification rule according to the number of failures and / or the error information.
3. The method according to claim 1, wherein The executing at least one first verification rule according to the second test result and one of the first test results includes: If the second test result fails, determining first error information of the second test result; Determine the number of occurrences of the first error message in one of the first test results; Obtaining a ratio of the number of occurrences to the number of failures in one of the first test results; At least one first validation rule is executed based on the ratio.
4. The method according to claim 3, wherein: The obtaining of the ratio of the number of occurrences to the number of failures comprises: When the number of failures meets a preset condition, the ratio is obtained.
5. The method according to claim 3, wherein Also includes: In a case where the ratio matches any one of the at least one first verification rule, a first notification rule corresponding to the verification rule is executed.
6. The method according to claim 1, wherein include: In the case where the second test result fails, the value of the number of failures is increased by 1, and then the at least one first verification rule is executed.
7. The method according to claim 6, wherein: The method further comprises: After the value of the number of failures is increased by 1, if any one of the at least one first verification rule is matched, the second notification rule corresponding to the verification rule is executed.
8. The method according to claim 1, wherein Also includes: Obtaining updated content of the object to be tested; At least one second test case is constructed according to the updated content to test the object to be tested.
9. The method according to claim 1, wherein Also includes: Setting N test tasks in a one-to-one correspondence with the N transaction types; Associating each of the N test tasks with at least one test script, wherein each of the test scripts includes at least one parameter of a first test case; The step of obtaining a test transaction request based on the M first test cases includes: The N types of test tasks are executed to call and execute at least one test script associated with each test task.
10. A testing device comprising: An object determination module, configured to determine an object to be tested, wherein the object to be tested is used to process a transaction request; a type acquisition module, configured to acquire N transaction types supported by the object to be tested, wherein the transaction type includes the type of the transaction request, and N is an integer greater than or equal to 1; a request acquisition module, configured to obtain a test transaction request based on M first test cases, wherein the first test cases include cases obtained based on at least one transaction function of each transaction type supported by the object to be tested, and M is an integer greater than or equal to 1; An object testing module, configured to test the object to be tested using the test transaction request; The step of testing the object to be tested by using the test transaction request includes: Divide the preset time period into S time intervals, where S is an integer greater than or equal to 1; Testing the object to be tested in each time interval of the S time intervals; The test is performed in I preset time periods, and each of the preset time periods is divided into S time intervals according to the same rule, where I is an integer greater than or equal to 2, including: Obtaining a first test result of the i-th time interval within each of the preset time periods, where i is an integer greater than or equal to 1 and i is less than or equal to S; executing at least one verification rule according to the first test results, wherein the first test results correspond one-to-one to an i-th time interval within the preset time period; The first test result corresponds to a first test case belonging to a first transaction type, where the first transaction type is any one of the N transaction types; the at least one verification rule includes at least one first verification rule, and the test is performed in the (I+1)th preset time period, where the (I+1)th preset time period is divided into the S time intervals, including: Obtaining a second test result of an i-th time interval within the (I+1)-th preset time period, wherein the second test result corresponds to the first test case; According to the second test result and I first test results, execute the at least one first verification rule, wherein the at least one first verification rule is configured according to the preset time period number and the number of failures.
11. An electronic device comprising: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors are enabled to perform the method according to any one of claims 1 to 9.
12. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to perform the method according to any one of claims 1 to 9.
13. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.
Citation Information
Patent Citations
Interface testing method and device, equipment, storage medium and program product
CN113434396A
Test prioritization techniques
US9032259B1