Independent assertion testing method, apparatus, device, storage medium and program product

Abstract

The disclosure provides an independent assertion test method, which can be applied to the field of financial technology or the field of software testing. The method comprises the following steps: determining first independent assertion information corresponding to the field of an output communication area message according to the field of the output communication area message; determining second independent assertion information according to a static call chain relationship and / or a dynamic call chain relationship; associating the first independent assertion information and the second independent assertion information with an automated test case; and running the automated test case multiple times to output multiple assertion test results. The first independent assertion information is a common assertion pre-encapsulated according to a field, and the second independent assertion information is a common assertion pre-encapsulated according to a service name. The disclosure also provides an independent assertion test device, equipment, a storage medium and a program product.

Description

Technical Field

[0001] This disclosure relates to the field of software testing technology, specifically to the field of assertion testing technology, and more specifically to an independent assertion testing method, apparatus, device, storage medium, and program product. Background Technology

[0002] In automated testing, it's necessary to automatically assert and verify transaction test results. A common approach is to embed assertions within automated scripts, judging the correctness of transactions based on expected business outcomes. However, for automated testing in the financial and banking sectors, the complexity of their business processes often leads to equally complex assertions. Take a transfer transaction as an example: it's necessary to check the balance of the sending account before and after the transaction, then assert the correctness of the formula "Post-transaction balance = Pre-transaction balance - Transfer amount" for the sending account. The assertion for the receiving account is similar. If verifying transfer transactions across different channels and card types, each transaction's automated test script must embed these complex balance assertion steps. This significantly increases the workload for testers, raises the cost of developing automated test cases, and reduces the efficiency of automated testing.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] In view of the above problems, this disclosure provides independent assertion testing methods, apparatus, devices, media, and program products to improve the efficiency of assertion testing.

[0005] According to the first aspect of this disclosure, an independent assertion test method is provided, comprising:

[0006] The first independent assertion information corresponding to the fields of the output communication area message is determined based on the fields of the output communication area message, wherein the output communication area message is the output message of the program under test.

[0007] The second independent assertion information is determined based on the static call chain relationship and / or the dynamic call chain relationship, wherein the static call chain relationship is obtained by performing static code scanning on the program under test, and the dynamic call chain relationship is determined based on the service log of the program under test;

[0008] The first independent assertion information and the second independent assertion information are associated with automated test cases, where the automated test cases are test cases of the program under test.

[0009] Run the automated test case multiple times to output multiple assertion test results.

[0010] The first independent assertion information is a public assertion pre-encapsulated based on a field, and the second independent assertion information is a public assertion pre-encapsulated based on a service name.

[0011] According to embodiments of this disclosure, determining the first independent assertion information corresponding to a field of the output communication area message based on the fields of the output communication area message includes:

[0012] The transaction status identifier and transaction return code are determined based on the fields of the output communication area message; and

[0013] The first independent assertion information is determined based on the transaction status identifier and the transaction return code.

[0014] The determination of the second independent assertion information based on the static call chain relationship and / or the dynamic call chain relationship includes:

[0015] The service name invoked by the tested program is determined based on the static call chain relationship and / or the dynamic call chain relationship; and

[0016] The second independent assertion information is determined based on the service name.

[0017] According to embodiments of this disclosure, it further includes:

[0018] The common assertion is adjusted based on the results of the multiple assertion tests; and

[0019] Recommend a common assertion based on the results of the multiple assertion tests.

[0020] According to embodiments of this disclosure, adjusting the common assertion based on the results of the plurality of assertion tests includes:

[0021] Based on the results of the multiple assertion tests, determine the input and expected values ​​of the common assertion under different test scenarios; and

[0022] The common assertion is adjusted according to the input and expected values ​​of the common assertion under different test scenarios.

[0023] According to embodiments of this disclosure, the step of recommending a public assertion based on the results of the plurality of assertion tests includes:

[0024] The running status of the assertion test is determined based on the results of the multiple assertion tests;

[0025] The validity of the public assertion is determined based on the runtime status of the assertion test; and

[0026] The public assertion is recommended based on its validity.

[0027] A second aspect of this disclosure provides an independent assertion test apparatus, comprising:

[0028] The first independent assertion determination module is used to determine the first independent assertion information corresponding to the fields of the output communication area message based on the fields of the output communication area message, wherein the output communication area message is the output message of the program under test.

[0029] The second independent assertion determination module is used to determine second independent assertion information based on static call chain relationships and / or dynamic call chain relationships, wherein the static call chain relationship is obtained by performing static code scanning on the program under test, and the dynamic call chain relationship is determined based on the service logs of the program under test;

[0030] The assertion association module is used to associate the first independent assertion information and the second independent assertion information with automated test cases, wherein the automated test cases are test cases of the program under test.

[0031] The output module is used to run the automated test case multiple times to output multiple assertion test results.

[0032] The first independent assertion information is a public assertion pre-encapsulated based on a field, and the second independent assertion information is a public assertion pre-encapsulated based on a service name.

[0033] According to embodiments of this disclosure, the first independent assertion determination module includes:

[0034] The first determining submodule is used to determine the transaction status identifier and transaction return code based on the fields of the output communication area message; and

[0035] The second determination submodule is used to determine the first independent assertion information based on the transaction status identifier and the transaction return code.

[0036] According to embodiments of this disclosure, the second independent assertion determination module includes:

[0037] The third determining submodule is used to determine the service name called by the tested program based on the static call chain relationship and / or the dynamic call chain relationship; and

[0038] The fourth determination submodule is used to determine the second independent assertion information based on the service name.

[0039] According to embodiments of this disclosure, it further includes:

[0040] An assertion adjustment module is used to adjust the common assertion based on the results of the multiple assertion tests; and

[0041] The recommendation module is used to recommend common assertions based on the results of the multiple assertion tests.

[0042] According to embodiments of this disclosure, the assertion adjustment module includes:

[0043] The fifth determining submodule is used to determine the input and expected values ​​of the common assertion under different test scenarios based on the results of the multiple assertion tests; and

[0044] The adjustment submodule is used to adjust the common assertion according to the input value and expected value of the common assertion under different test scenarios.

[0045] According to embodiments of this disclosure, the recommendation module includes:

[0046] The sixth determination submodule is used to determine the running status of the assertion test based on the results of the multiple assertion tests;

[0047] The seventh determination submodule is used to determine the validity of the common assertion based on the running status of the assertion test; and

[0048] The recommendation submodule is used to recommend the public assertions based on their validity.

[0049] A third aspect of this 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 perform the above-described independent assertion test method.

[0050] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the above-described independent assertion test method.

[0051] The fifth aspect of this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described independent assertion test method.

[0052] An independent assertion testing method provided by embodiments of this disclosure determines first independent assertion information by outputting communication area message fields, determines second independent assertion information based on the static and / or dynamic call chains of the program under test, associates the first and second independent assertion information with test cases of the program under test, and runs the automated test cases multiple times to output multiple assertion test results. Compared with related technologies, the independent assertion testing method of embodiments of this disclosure eliminates the need for testers to manually select and insert assertions, automatically matching assertions based on test cases, thus improving assertion testing efficiency. Attached Figure Description

[0053] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0054] Figure 1 The illustration schematically depicts application scenarios of independent assertion testing methods, apparatus, devices, media, and program products according to embodiments of this disclosure;

[0055] Figure 2 This diagram schematically illustrates an independent assertion testing system architecture according to an embodiment of the present disclosure;

[0056] Figure 3 A flowchart illustrating an independent assertion test method according to an embodiment of the present disclosure is shown schematically;

[0057] Figure 4 A flowchart illustrating a method for determining a first independent assertion information according to an embodiment of the present disclosure is shown schematically.

[0058] Figure 5 A flowchart illustrating a second independent assertion information determination method according to an embodiment of the present disclosure is shown schematically.

[0059] Figure 6 The flowchart illustrates the automatic analysis and judgment of the input and expected values ​​of associated public assertions based on the results returned by assertion tests.

[0060] Figure 7a This schematically illustrates a flowchart of adjusting the common assertion based on the results of the multiple assertion tests;

[0061] Figure 7b A flowchart illustrating the recommendation of a common assertion based on the results of the multiple assertion tests is shown in the illustration.

[0062] Figure 8 A schematic block diagram of an independent assertion test apparatus according to an embodiment of the present disclosure is shown.

[0063] Figure 9 A block diagram schematically illustrates an electronic device suitable for implementing an independent assertion test method according to an embodiment of the present disclosure. Detailed Implementation

[0064] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0065] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0066] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0067] When using expressions such as "at least one of A, B, and C", they should generally be interpreted in accordance with the meaning that is commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.).

[0068] First, the terminology appearing in the embodiments of this disclosure will be explained:

[0069] Assertion testing: An assertion is a Boolean expression at a specific point in a program. In the field of testing, assertion statements need to be added to the test script to perform assertion testing in order to verify whether the test results are correct or meet expectations.

[0070] Independent assertions: In this embodiment of the disclosure, assertions are classified according to actual test scenarios or test verification functions and encapsulated into independent public assertions to increase the reusability of assertions.

[0071] Static call chain: In the static call method, the calling interface is explicitly defined in the object component used by the client. The client program can directly access the properties and methods of a remote call object. The static call chain can be obtained by scanning the program source code.

[0072] Dynamic call chain: The dynamic call method refers to the client program not specifying the attributes and methods of the remote call object during construction and generation. This information needs to be determined during program execution. The dynamic call chain can usually be obtained by accessing the service log.

[0073] Currently, automated testing requires automatically performing assertion verification on transaction test scripts. A common approach is to embed assertions within the automated script, judging the correctness of the transaction based on the expected business outcome. For example, in TestNG framework test scripts, a simple method is to use methods like `Assert.assertEquals` for assertion judgment. However, for automated testing in the financial and banking sectors, the business processes are often more complex, leading to more complex assertions. Taking a transfer transaction as an example, it's necessary to check the balance of the sending account before and after the transaction, then assert the correctness of the statement "Post-transaction balance = Pre-transaction balance - Transfer amount" for the sending account. The assertion for the receiving account is similar. If verifying transfer transactions across different channels and card types, then each transaction's automated test script must embed complex steps involving these balance assertions.

[0074] Based on the aforementioned technical problems, embodiments of this disclosure provide an independent assertion testing method. The method includes: determining first independent assertion information corresponding to fields in an output communication area message, wherein the output communication area message is the output message of the program under test; determining second independent assertion information based on a static call chain relationship and / or a dynamic call chain relationship, wherein the static call chain relationship is obtained by performing static code scanning on the program under test, and the dynamic call chain relationship is determined based on the service logs of the program under test; associating the first and second independent assertion information with automated test cases, wherein the automated test cases are test cases of the program under test; running the automated test cases multiple times to output multiple assertion test results, wherein the first independent assertion information is a pre-encapsulated common assertion based on fields, and the second independent assertion information is a pre-encapsulated common assertion based on service names.

[0075] Figure 1 The illustration schematically depicts application scenarios of independent assertion testing methods, apparatus, devices, media, and program products according to embodiments of the present disclosure.

[0076] like Figure 1 As shown, application scenario 100 according to this embodiment may include a service testing scenario. Network 104 is used as a medium to provide a communication link between terminal devices 101, 102, 103 and server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0077] Testers 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 media platform software, etc. (for example only).

[0078] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0079] Server 105 can be an independent assertion matching server. For input automated test cases, such as test commands issued by testers using terminal devices 101, 102, and 103, this independent assertion matching server can automatically match common assertions to the automated test cases and verify the test results.

[0080] It should be noted that the independent assertion testing method provided in this disclosure embodiment can generally be executed by server 105. Correspondingly, the independent assertion testing device provided in this disclosure embodiment can generally be located in server 105. The independent assertion testing method provided in this disclosure embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the independent assertion testing device provided in this disclosure embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0081] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0082] It should be noted that the independent assertion testing method and apparatus determined in the embodiments of this disclosure can be used in the field of automated testing in the financial field, and can also be used in any field other than the financial field. The application field of the independent assertion testing method and apparatus determined in the embodiments of this disclosure is not limited.

[0083] Figure 2 A schematic diagram illustrating an independent assertion testing system architecture according to an embodiment of this disclosure is provided. Figure 2As shown, the system includes an assertion encapsulation unit 01, a source code analysis unit 02, a log analysis unit 03, an auto-assembly unit 04, and an automatic testing unit 05. Assertion Encapsulation Unit 01: For testing program services, after the test is completed, test assertions are generally initiated to determine whether the program service's results meet expectations. Test assertions are mainly divided into two categories: one is whether the field values ​​in the output (return) communication area are correct, and the other is whether the database table modifications are correct. Both of these can be encapsulated as independent assertions. Source Code Analysis Unit 02: Automatically analyzes the definition of the output communication area of ​​the program service under test. This is generally a JAVA program, and all fields of the output communication area definition class can be obtained through reflection. It automatically analyzes the external calls of the program service under test to obtain the static call chain relationship of the program. Log Analysis Unit 03: Based on the logs recorded by the program service under test during the test, it analyzes which program services this program service called, obtaining the dynamic call chain relationship of the program. Auto-assembly Unit 04: Combining the analysis results of the source code analysis unit and the log analysis unit, it automatically assembles the corresponding common assertions into the automated test script. Automated Test Unit 05: After automatically associating common assertions of fields and database tables with the test case, the automated test case is run automatically, and the results are used to determine whether the associated common assertions are recommended.

[0084] The following will be based on Figure 1 The scene described and Figure 2 The system architecture, through Figures 3 to 7b The independent assertion testing method of the present disclosure embodiments is described in detail.

[0085] Figure 3 A flowchart illustrating an independent assertion testing method according to an embodiment of this disclosure is shown schematically. Figure 3 As shown, the independent assertion test method of this embodiment includes operations S210 to S240.

[0086] In operation S210, the first independent assertion information corresponding to the fields of the output communication area message is determined based on the fields of the output communication area message.

[0087] According to embodiments of this disclosure, the output communication area message is the output message of the program under test.

[0088] According to embodiments of this disclosure, the first independent assertion information is a public assertion pre-encapsulated based on a field, and the second independent assertion information is a public assertion pre-encapsulated based on a service name.

[0089] In one example, test assertions are mainly classified into two categories: one is whether the field values ​​in the output (return) communication area are correct, and the other is whether the database table modifications are correct. Both of these can be encapsulated as independent assertions.

[0090] Specifically, the test assertions in the output communication area can be encapsulated into the first independent assertion information. Taking the transaction return code as an example, the output communication area generally includes a common communication area that returns key information such as whether the transaction was successful, the transaction return code, and the error description.

[0091]

[0092] This ReturnInfo can be encapsulated into a "common return code assertion," which checks if transok is 0; if so, the assertion succeeds. Alternatively, it checks if return_code is a specific return code; if so, the assertion succeeds. Other specific return codes can be similarly encapsulated into common assertions.

[0093] For test assertions related to database table modifications, they can be encapsulated into a second, independent assertion. Taking the update of the account transaction amount table as an example, it generally requires at least two fields: account and amount.

[0094] ACCNO: DECIMAL(17,0)

[0095] BALANCE: DECIMAL(17,0)

[0096] Updates to the account balance table are typically encapsulated in a public service such as BalanceBOS. All operations that require updating the table are completed by calling this public service.

[0097] This account balance table can be encapsulated into a "common amount assertion." The input is the account, and the expected amount is the balance. It can query whether the balance of the latest record for that account is the expected amount; if so, the assertion succeeds. Modifications to other database tables (such as transaction sequence numbers, transaction details, etc.) can also be encapsulated into common assertions in a similar way.

[0098] The first independent assertion information can be determined based on the fields in the output communication area message, which is the output message of the program under test. For example, the first independent assertion information can be determined as the transaction return code common assertion based on the transaction return code in the output message. For details, please refer to [link to relevant documentation]. Figure 4 Operations S211 to S212 are shown. They will not be described in detail here.

[0099] In operation S220, the second independent assertion information is determined based on the static call chain relationship and / or the dynamic call chain relationship.

[0100] According to embodiments of this disclosure, the static call chain relationship is obtained by performing static code scanning on the program under test, and the dynamic call chain relationship is determined based on the service logs of the program under test.

[0101] In one example, static call chain relationships obtained through static code scanning are used. For instance, if program A calls programs B and C, and program B calls program D, the service names in the static call chain relationship are used to determine if there are any public assertions corresponding to those service names, thus determining the second independent assertion information. Similarly, the second independent assertion information can also be determined through dynamic call chain relationships, which are determined by scanning service call log records. For details, please refer to [link to relevant documentation]. Figure 5 Operations S221 to S222 are shown.

[0102] In operation S230, the first independent assertion information and the second independent assertion information are associated with the automated test case.

[0103] According to embodiments of this disclosure, the automated test cases are test cases of the program under test.

[0104] In operation S240, the automated test case is run multiple times to output multiple assertion test results.

[0105] In one example, the first and second independent assertion information determined by operations S210 and S220 are associated with the test cases of the program under test. This involves inserting corresponding assertion judgment statements into the test case script. These statements are pre-encapsulated. Compared to related technologies, the method of this disclosure significantly improves the reusability of assertions. In complex business testing scenarios, testers do not need to manually configure and insert assertions, greatly improving testing efficiency. Multiple associated automated test cases are run to output multiple assertion test results. The input and expected values ​​of the associated common assertions are automatically analyzed and judged based on the assertion test results. For details, please refer to [link to documentation]. Figure 6 Operations S310 and S320 are shown.

[0106] The independent assertion testing method provided by the embodiments of this disclosure analyzes the source code of the program under test and test logs, modifies the communication area return fields and database tables, automatically encapsulates reusable independent assertions, and automatically generates assertions for various output fields and database tables. Automated test cases only need to be built like building blocks, associating them with the corresponding assertion functions, effectively reducing the development cost of automated test scripts and improving the reusability of automated assertions.

[0107] Figure 4 A flowchart illustrating a first independent assertion information determination method according to an embodiment of this disclosure is shown schematically. Figure 4 As shown, operation S210 includes operations S211 to S212.

[0108] In operation S211, the transaction status identifier and transaction return code are determined based on the fields of the output communication area message.

[0109] In operation S212, the first independent assertion information is determined based on the transaction status identifier and the transaction return code.

[0110] In one example, the definition of the output communication area of ​​the program service under test is analyzed. This is typically a Java program, and all fields of the output communication area definition class can be obtained through reflection. Specifically, for the output communication area definition class, all field attributes of that type can be obtained using `getClass().getDeclaredFields()` (by looping through and retrieving fields from nested sub-objects), and the type name can be obtained using `getType().getSimpleName()`. Based on the analysis results of the output communication area of ​​the program service under test, if the input communication area contains fields encapsulated with public assertions, this test script automatically associates these public assertions and sets the association status to "suggested". For example, if the communication area contains a `ReturnInfo` field, it can automatically associate the "return code public assertion".

[0111] Figure 5 A flowchart illustrating a second independent assertion information determination method according to an embodiment of this disclosure is shown schematically. Figure 5 As shown, operation S220 includes operations S221 to S222.

[0112] In operation S221, the service name called by the tested program is determined based on the static call chain relationship and / or the dynamic call chain relationship.

[0113] In operation S222, a second independent assertion information is determined based on the service name.

[0114] In one example, the methods for obtaining static and dynamic call chain relationships are first introduced. The system automatically analyzes the external calls of the program service under test to obtain its static call chain relationship. Specifically, code scanning reveals that program A under test calls programs B and C, and then program B calls program D. This results in two call chain relationships: A->B->D and A->C. Based on the logs recorded by the program service under test during the test, the system analyzes which other programs this program service called to obtain its dynamic call chain relationship. The program call chain can be used to track all test execution logs; therefore, analyzing the logs of previously run test transactions yields a list of programs that were actually called during the test.

[0115] Specifically, one implementation scheme for in-application call chain tracing in Java is as follows:

[0116] 1. For each request from the channel, a unique identifier (denoted as traceId) is assigned. The traceId can be obtained through methods such as TraceContext.ctx.getTraceId().

[0117] 2. For each request to the controller's business logic, you can use Spring MVC's HandlerInterceptor.preHandle method to record and pass the traceId value. At the same time, add the traceId identifier to the configuration file of the underlying logging system so that the traceId is displayed in the log.

[0118] 3. By combining the log retrieval function, you can locate which procedures a transaction request went through.

[0119] Based on the static or dynamic call chain of the service being tested, determine the name of the service to be called. If a service is called and it already has a public assertion encapsulation, this test script will automatically associate it with that public assertion and set the association to optional. For example, if the BalanceBOS service is called, this test case will automatically be associated with a "monetary public assertion".

[0120] In this embodiment of the disclosure, the input values ​​and expected values ​​of associated public assertions can also be automatically determined to achieve automatic configuration of assertions. Figure 6 The flowchart illustrates the automatic analysis and judgment of the input and expected values ​​of associated public assertions based on the results returned by assertion tests. Figure 7a A flowchart illustrating the adjustment of the common assertion based on the results of the multiple assertion tests is shown. Figure 7b A flowchart illustrating the recommendation of a common assertion based on the results of the multiple assertion tests is shown.

[0121] like Figure 6 As shown, after obtaining the assertion test result, operations S310 and S320 are also included.

[0122] In operation S310, the common assertion is adjusted based on the results of the multiple assertion tests.

[0123] For associated public assertions, the expected and output values ​​of the assertions can be automatically matched, and adjustments can be made based on the assertion test results. For details, please refer to [link to documentation / reference]. Figure 7a Operations S311 and S312 are shown.

[0124] like Figure 7a As shown, operation S310 includes operations S311 to 312.

[0125] In operation S311, the input value and expected value of the common assertion under different test scenarios are determined based on the results of the multiple assertion tests.

[0126] In operation S312, the common assertion is adjusted according to the input value and expected value of the common assertion under different test scenarios.

[0127] In one example, for associated public assertions, the expected values ​​of the assertions can be automatically matched. Specifically, taking the "Return Code Public Assertion" in the output communication area as an example, after running it multiple times, if it is highly likely that the output communication area will return a transok field value of 0 (transaction successful) and return_code of 0 each time, then the expected values ​​of the "Return Code Public Assertion" for this case can be set to transok == 0 and return_code == 0; if it is highly likely that the output communication area will return a transok field value of 1 each time, i.e., the transaction failed, and it is highly likely that the output communication area will return a return_code of 2233 each time (this transaction code indicates that the customer's password is incorrect), then the expected values ​​of the "Return Code Public Assertion" for this case can be set to transok == 1 and return_code == 2233, indicating that this case is a test scenario testing an incorrect customer password.

[0128] Similarly, taking the "Amount Common Assertion" in database table modification as an example, the system automatically analyzes and matches the corresponding ACCNO and BALANCE fields in the input communication area of ​​the tested program service. After multiple test runs, it was found that using the account field value of ACCNO to query the latest amount in the account transaction amount table, the latest amount was decreasing each time, and the amount of decrease was equal to the amount field value of BALANCE. Therefore, it can be determined that the account is currently engaged in business scenarios such as withdrawals or transfers. Thus, the input value of the "Amount Common Assertion" in this case is automatically set to the ACCNO field value, and the expected value of the assertion is the original amount in the account transaction amount table minus the BALANCE field value.

[0129] In operation S320, a common assertion is recommended based on the results of the multiple assertion tests.

[0130] In one example, an automated test case associated with a common assertion is run multiple times. Based on the results, the recommended value of the associated common assertion is determined, resulting in a steady-state automated test case. See details in [link to documentation]. Figure 7b Operations S321 to S323 are shown.

[0131] like Figure 7b As shown, operation S320 includes operations S321 to S323.

[0132] In operation S321, the running status of the assertion test is determined based on the results of the multiple assertion tests.

[0133] In operation S322, the validity of the public assertion is determined based on the running status of the assertion test.

[0134] In operation S323, the public assertion is recommended based on the validity of the public assertion.

[0135] In one example, after determining the input and expected values ​​of a stable public assertion, the validity of the public assertion in the automated test case is defined. If the automated test case succeeds every time it runs, the public assertion is defined as strongly recommended (e.g., marked in green in the test case); if it partially succeeds, the public assertion is recommended (e.g., marked in blue in the test case); if it fails every time, it is set to neutral (e.g., marked in red in the test case). For public assertions that are not strongly recommended, testers can manually intervene to determine their necessity. If necessary, adjustments can be made based on the actual situation to ensure the assertion's validity. This reduces the development cost of automated test cases and improves the efficiency of automated testing.

[0136] The independent assertion testing method provided in this disclosure analyzes the source code and test logs of the program under test, modifies the communication area return fields and database tables, automatically encapsulates reusable independent assertions, and automatically assembles and recommends them into automated test cases. It has at least the following technical effects:

[0137] 1. Decoupling of automated test scripts and assertions. This separates automated test scripts from assertions, making the assertion module independent. This allows scripts to focus on business implementation, while assertions focus on business verification, ensuring each performs its specific function clearly and efficiently.

[0138] 2. Automated generation of assertions for various output fields and database tables. Automated test cases only require building blocks, associating them with the corresponding assertion functions, effectively reducing the development cost of automated test scripts and improving the reusability of automated assertions.

[0139] 3. Based on the source code and test logs of the program under test, automatically assemble the corresponding common assertions for the automated test cases, and obtain the recommended values ​​of the common assertions through an adaptive approach, thereby reducing the development cost of automated test cases and improving the efficiency of automated testing.

[0140] Based on the above-described independent assertion testing method, this disclosure also provides an independent assertion testing apparatus. The following will be combined with... Figure 8 The device is described in detail.

[0141] Figure 8A schematic block diagram of an independent assertion test apparatus according to an embodiment of the present disclosure is shown.

[0142] like Figure 8 As shown, the independent assertion testing device 800 of this embodiment includes a first independent assertion module 810, a second independent assertion module 820, an assertion association module 830, and an output module 840.

[0143] The first independent assertion determination module 810 is used to determine the first independent assertion information corresponding to the fields of the output communication area message based on the fields of the output communication area message, wherein the output communication area message is the output message of the program under test. In one embodiment, the first independent assertion determination module 810 can be used to perform the operation S210 described above, which will not be repeated here.

[0144] The second independent assertion determination module 820 is used to determine second independent assertion information based on static call chain relationships and / or dynamic call chain relationships, wherein the static call chain relationship is obtained by performing static code scanning on the program under test, and the dynamic call chain relationship is determined based on the service logs of the program under test. In one embodiment, the second independent assertion determination module 820 can be used to perform the operation S220 described above, which will not be repeated here.

[0145] The assertion association module 830 is used to associate the first independent assertion information and the second independent assertion information with automated test cases, wherein the automated test cases are test cases of the program under test. In one embodiment, the assertion association module 830 can be used to perform the operation S230 described above, which will not be repeated here.

[0146] The output module 840 is used to run the automated test cases multiple times to output multiple assertion test results. The first independent assertion information is a pre-encapsulated common assertion based on a field, and the second independent assertion information is a pre-encapsulated common assertion based on a service name. In one embodiment, the output module 840 can be used to perform the operation S240 described above, which will not be repeated here.

[0147] According to embodiments of this disclosure, the first independent assertion determination module 810 includes: a first determination submodule and a second determination submodule.

[0148] The first determining submodule is used to determine the transaction status identifier and transaction return code based on the fields of the output communication area message. In one embodiment, the first determining submodule can be used to perform the operation S211 described above, which will not be repeated here.

[0149] The second determining submodule is used to determine the first independent assertion information based on the transaction status identifier and the transaction return code. In one embodiment, the second determining submodule can be used to perform the operation S212 described above, which will not be repeated here.

[0150] According to embodiments of this disclosure, the second independent assertion determination module 820 includes a third determination submodule and a fourth determination submodule.

[0151] The third determining submodule is used to determine the service name called by the tested program based on the static call chain relationship and / or the dynamic call chain relationship. In one embodiment, the third determining submodule can be used to perform the operation S221 described above, which will not be repeated here.

[0152] The fourth determining submodule is used to determine the second independent assertion information based on the service name. In one embodiment, the fourth determining submodule can be used to perform the operation S222 described above, which will not be repeated here.

[0153] According to embodiments of this disclosure, it further includes: an assertion adjustment module 850 and a recommendation module 860.

[0154] The assertion adjustment module 850 is used to adjust the common assertion based on the results of the plurality of assertion tests. In one embodiment, the assertion adjustment module 850 may be used to perform the operation S310 described above, which will not be repeated here.

[0155] The recommendation module 860 is used to recommend common assertions based on the results of the plurality of assertion tests. In one embodiment, the recommendation module 860 can be used to perform the operation S320 described above, which will not be repeated here.

[0156] According to embodiments of this disclosure, the assertion adjustment module 850 includes a fifth determination submodule and an adjustment submodule.

[0157] The fifth determining submodule is used to determine the input value and expected value of the common assertion under different test scenarios based on the results of the multiple assertion tests. In one embodiment, the fifth determining submodule can be used to perform the operation S311 described above, which will not be repeated here.

[0158] The adjustment submodule is used to adjust the common assertion according to the input and expected values ​​of the common assertion under different test scenarios. In one embodiment, the adjustment submodule can be used to perform the operation S312 described above, which will not be repeated here.

[0159] According to embodiments of this disclosure, the recommendation module includes: a sixth determination submodule, a seventh determination submodule, and a recommendation submodule.

[0160] The sixth determining submodule is used to determine the running state of the assertion test based on the results of the plurality of assertion tests. In one embodiment, the sixth determining submodule can be used to perform the operation S321 described above, which will not be repeated here.

[0161] The seventh determination submodule is used to determine the validity of the common assertion based on the running status of the assertion test. In one embodiment, the seventh determination submodule can be used to perform the operation S322 described above, which will not be repeated here.

[0162] The recommendation submodule is used to recommend the public assertion based on its validity. In one embodiment, the recommendation submodule can be used to perform the operation S323 described above, which will not be repeated here.

[0163] According to embodiments of this disclosure, any plurality of modules among the first independent assertion module 810, the second independent assertion module 820, the assertion association module 830, and the output module 840 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules may be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the first independent assertion module 810, the second independent assertion module 820, the assertion association module 830, and the output module 840 may be at least partially implemented as hardware circuitry, 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-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these methods. Alternatively, at least one of the first independent assertion module 810, the second independent assertion module 820, the assertion association module 830, and the output module 840 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0164] Figure 9 A block diagram schematically illustrates an electronic device suitable for implementing an independent assertion test method according to an embodiment of the present disclosure.

[0165] like Figure 9As shown, an electronic device 900 according to an embodiment of the present disclosure includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 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.

[0166] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 902 and / or RAM 903. It should be noted that the programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0167] According to embodiments of this disclosure, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0168] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the independent assertion test method according to embodiments of this disclosure.

[0169] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0170] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the independent assertion testing method provided in embodiments of this disclosure.

[0171] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0172] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0173] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0174] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational 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 execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0175] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0176] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0177] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. An independent assertion testing method, characterized in that, The testing method includes: At least one public assertion is pre-encapsulated, the public assertion including a first type of public assertion and a second type of public assertion, wherein the first type of public assertion is encapsulated according to a preset field structure in the output communication area message, and the second type of public assertion is encapsulated according to the service name; Based on the fields of the output communication area message, determine the first type of common assertion corresponding to the fields of the output communication area message, as the first independent assertion information, wherein the output communication area message is the output message of the program under test; The name of the service called by the tested program is determined based on the static call chain relationship and / or the dynamic call chain relationship; Based on the service name, a second type of public assertion corresponding to the service name is determined as the second independent assertion information; wherein, the static call chain relationship is obtained by performing static code scanning on the program under test, and the dynamic call chain relationship is determined based on the service log of the program under test; The first independent assertion information and the second independent assertion information are associated with automated test cases, where the automated test cases are test cases of the program under test. Run the automated test case multiple times to output multiple assertion test results.

2. The test method according to claim 1, characterized in that, The step of determining the first independent assertion information corresponding to the fields of the output communication area message based on the fields of the output communication area message includes: The transaction status identifier and transaction return code are determined based on the fields of the output communication area message; and The first independent assertion information is determined based on the transaction status identifier and the transaction return code.

3. The test method according to claim 1 or 2, characterized in that, Also includes: The common assertion is adjusted based on the results of the multiple assertion tests; as well as Recommend a common assertion based on the results of the multiple assertion tests.

4. The test method according to claim 3, characterized in that, The adjustment of the common assertion based on the results of the multiple assertion tests includes: Based on the results of the multiple assertion tests, determine the input and expected values ​​of the common assertion under different test scenarios; and The common assertion is adjusted according to the input and expected values ​​of the common assertion under different test scenarios.

5. The test method according to claim 4, characterized in that, The recommendation of common assertions based on the results of the multiple assertion tests includes: The running status of the assertion test is determined based on the results of the multiple assertion tests; The validity of the public assertion is determined based on the runtime status of the assertion test; and The public assertion is recommended based on its validity.

6. An independent assertion testing device, characterized in that, The testing apparatus includes: An encapsulation module is used to pre-encapsulate at least one public assertion, which includes a first type of public assertion and a second type of public assertion, wherein the first type of public assertion is encapsulated according to a preset field structure in the output communication area message, and the second type of public assertion is encapsulated according to the service name; The first independent assertion determination module is used to determine a first type of common assertion corresponding to the fields of the output communication area message based on the fields of the output communication area message, as the first independent assertion information, wherein the output communication area message is the output message of the program under test. The second independent assertion determination module is used to determine the service name called by the program under test based on the static call chain relationship and / or the dynamic call chain relationship; and to determine the second type of public assertion corresponding to the service name as the second independent assertion information based on the service name; wherein the static call chain relationship is obtained by performing static code scanning on the program under test, and the dynamic call chain relationship is determined based on the service log of the program under test. The assertion association module is used to associate the first independent assertion information and the second independent assertion information with automated test cases, wherein the automated test cases are test cases of the program under test. The output module is used to run the automated test case multiple times to output multiple assertion test results.

7. An electronic device, comprising: One or more processors; Storage device 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 perform the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 5.

9. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 5.

Images