Software testing method and device, program product and electronic equipment

Abstract

The invention discloses a software testing method and device, a program product and electronic equipment, and relates to the field of financial science and technology or other related fields, and the software testing method comprises the steps: initiating a transaction process recording request in an original transaction system, obtaining test data, generating test cases of multiple transaction dimensions based on the test data, and recording the test cases of multiple transaction dimensions according to the test cases. And constructing a test script based on all the test cases, running the test script on the to-be-tested software to obtain test output corresponding to each test case, and generating a test report based on the expected output and the test output corresponding to each test case. According to the method and the device, the technical problem of relatively low efficiency of testing the software in related technologies is solved.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and more specifically, to a software testing method and apparatus, program product, and electronic device. Background Technology

[0002] During the migration of trading operations from the mainframe system to the platform system, ensuring trading stability and maintaining a positive customer experience are fundamental requirements. Therefore, it is necessary to test the platform system (i.e., the software to be tested) in advance.

[0003] In related technologies, software testing typically relies on manual operation, initiating and checking transactions one by one to ensure the accuracy of the transaction process and the continuity of the customer experience. However, manual testing requires a significant amount of time and effort when faced with massive amounts of transaction data and complex transaction logic, resulting in low testing efficiency.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a software testing method, apparatus, program product, and electronic device to at least address the technical problem of low efficiency in software testing in related technologies.

[0006] According to one aspect of the present invention, a software testing method is provided, comprising: initiating a transaction process recording request in an original transaction system to obtain test data, wherein the original transaction system refers to the system currently executing the transaction process by a financial institution; generating test cases for multiple transaction dimensions based on the test data, wherein each test case includes at least: expected output; constructing a test script based on all test cases; running the test script on the software to be tested to obtain the test output corresponding to each test case, and generating a test report based on the expected output and test output corresponding to each test case.

[0007] Furthermore, the steps of initiating a transaction process recording request in the original trading system to obtain test data include: creating a test environment on the original trading system; executing a pre-set transaction process in the test environment; and recording the execution operations of the transaction process using a recording tool during the execution of the transaction process to obtain test data. The execution operations include at least: user operations and system event operations.

[0008] Furthermore, the steps for generating test cases for multiple transaction dimensions based on test data include: determining multiple transaction dimensions based on the transaction scenario of the transaction process executed by the original transaction system; determining the input, expected output, and execution flow for each transaction dimension based on test data, wherein the execution flow includes: multiple operations from input to expected output and the execution relationship between each operation; and generating test cases for each transaction dimension based on the input, expected output, and execution flow for that transaction dimension.

[0009] Furthermore, the steps for constructing test scripts based on all test cases include: sorting all test cases based on the transaction dimension to obtain a sorting result; using a combinatorial testing algorithm to traverse all test cases based on the sorting result to determine whether there are identical test cases, where identical test cases refer to test cases with the same input and the same expected output; if identical test cases exist, generating new test cases corresponding to the new transaction dimension based on the transaction dimension corresponding to the identical test cases, and replacing the identical test cases with the new test cases to obtain a target test case set; constructing test combinations, and constructing test scripts based on the target test case set and the test combinations, where the test combination is a combination used to test all test cases.

[0010] Furthermore, the steps for constructing test combinations include: determining multiple test factors based on the trading scenario of the trading process executed by the original trading system; determining the level value corresponding to each test factor; and arbitrarily combining each level value corresponding to all test factors in pairs to obtain multiple test combinations.

[0011] Furthermore, the steps of running test scripts on the software under test to obtain the test output corresponding to each test case include: deploying all test cases in the test environment on the software under test; running test scripts in the test environment through a simulation system to replay all test cases by calling each test combination; recording the replay process of each test case using a recording tool to obtain replay data, and recording the performance data of the software under test during the replay of test cases; and determining the test output corresponding to each test case based on the replay data.

[0012] Furthermore, the steps for generating a test report based on the expected output and test output for each test case include: determining whether the expected output and test output for each test case are consistent; in the case where the expected output and test output for a test case are inconsistent, determining that the replay has failed, and locating the cause of failure based on the log data of the simulation system; obtaining the input parameters during the replay of the target test case, and determining the call parameter status of the software under test based on the input parameters, wherein the target test case refers to the test case where the expected output and test output are inconsistent; determining the performance status of the software under test based on performance data; and generating a test report based on the cause of failure, the call parameter status, and the performance status.

[0013] According to another aspect of the present invention, a software testing apparatus is also provided, comprising: an initiation unit, configured to initiate a transaction process recording request in an original transaction system to obtain test data, wherein the original transaction system refers to the system currently executing the transaction process by a financial institution; a generation unit, configured to generate test cases for multiple transaction dimensions based on the test data, wherein each test case includes at least: expected output; a construction unit, configured to construct a test script based on all test cases; and a running unit, configured to run the test script on the software to be tested to obtain the test output corresponding to each test case, and generate a test report based on the expected output and test output corresponding to each test case.

[0014] Furthermore, the initiating unit includes: a first creation module for creating a test environment on the original trading system; a first execution module for executing a pre-set trading process on the test environment; and a first recording module for recording the execution operations of the trading process using a recording tool to obtain test data, wherein the execution operations include at least: user operations and system event operations.

[0015] Furthermore, the generation unit includes: a first determining module, used to determine multiple transaction dimensions based on the transaction scenario of the transaction process executed by the original transaction system; a second determining module, used to determine the input, expected output, and execution process under each transaction dimension based on test data, wherein the execution process includes: multiple operations from input to expected output and the execution relationship between each operation; and a first generation module, used to generate test cases for each transaction dimension based on the input, expected output, and execution process under the transaction dimension.

[0016] Furthermore, the construction unit includes: a first sorting module, used to sort all test cases based on the transaction dimension to obtain a sorting result; a first judgment module, used to traverse all test cases using a combination testing algorithm based on the sorting result to determine whether there are identical test cases, wherein identical test cases refer to test cases with the same input and the same expected output; a second generation module, used to generate new test cases corresponding to the new transaction dimension based on the transaction dimension corresponding to the identical test cases when identical test cases exist, and replace the identical test cases with the new test cases to obtain a target test case set; and a first construction module, used to construct test combinations and construct test scripts based on the target test case set and the test combinations, wherein the test combination is a combination used to test all test cases.

[0017] Furthermore, the first construction module includes: a first determining submodule, used to determine multiple test factors based on the trading scenario of the trading process executed by the original trading system; a second determining submodule, used to determine the level value corresponding to each test factor; and a first combining submodule, used to arbitrarily combine each level value corresponding to all test factors in pairs to obtain multiple test combinations.

[0018] Furthermore, the execution unit includes: a first deployment module, used to deploy all test cases in the test environment on the software under test; a first execution module, used to run test scripts in the test environment through a simulation system to replay all test cases by calling each test combination; a second recording module, used to record the replay process of each test case using a recording tool to obtain replay data, and record the performance data of the software under test during the replay of test cases; and a third determination module, used to determine the test output corresponding to each test case based on the replay data.

[0019] Furthermore, the execution unit also includes: a second judgment module, used to determine whether the expected output and the test output corresponding to each test case are consistent; a first location module, used to determine the replay failure when there is a discrepancy between the expected output and the test output corresponding to a test case, and to locate the cause of the failure based on the log data of the simulation system; a first acquisition module, used to acquire the input parameters during the replay of the target test case, and to determine the calling parameter status of the software under test based on the input parameters, wherein the target test case refers to the test case where the expected output and the test output are inconsistent; a fourth determination module, used to determine the performance status of the software under test based on performance data; and a third generation module, used to generate a test report based on the cause of failure, the calling parameter status, and the performance status.

[0020] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described software testing methods.

[0021] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described software testing methods.

[0022] In this invention, a transaction process recording request is initiated in the original transaction system to obtain test data. Based on the test data, test cases for multiple transaction dimensions are generated. Based on all test cases, test scripts are constructed. The test scripts are run on the software to be tested to obtain the test output corresponding to each test case. Based on the expected output and test output corresponding to each test case, a test report is generated, thereby solving the technical problem of low efficiency in software testing in related technologies.

[0023] In this invention, a recording and playback method is adopted. By initiating a recording request for the transaction process in the original trading system, comprehensive test data is obtained. Then, based on this test data, the Pairwise algorithm (a combined testing algorithm) is used to generate test cases covering multiple transaction dimensions. Based on these test cases, an automated test script is built. This script can automatically run on the software under test, obtaining real-time test output for each test case. By comparing the expected output with the actual output of each test case, a detailed test report is automatically generated. In this way, not only is testing efficiency and coverage improved, but labor costs are also effectively reduced. This ensures the stability and reliability of the trading system after it is migrated to a new platform. Thus, it solves the technical problem that manual testing is difficult to cover all scenarios under large-scale transaction data and complex transaction types, which affects software quality and user experience. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0025] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a software testing method is shown.

[0026] Figure 2 This is a flowchart of a software testing method according to Embodiment 1 of the present invention;

[0027] Figure 3 This is a schematic diagram of an optional software testing apparatus according to an embodiment of the present invention;

[0028] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0032] Simulation systems are a technology that uses computers to simulate the operation of real systems. They can simulate the behavior of actual systems, thereby helping to understand how the system works, predict the system's behavior, and optimize system design.

[0033] Recording and playback: Used to record and reproduce the execution process of a computer program or system. During the recording phase, the system records user operations, program execution flow, data transfer, and other information, saving them in a recording file. During the playback phase, the system re-executes the same operation flow according to the information in the recording file to restore the original execution process.

[0034] It should be noted that all relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected and involved in this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and it does not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface. The relevant information is obtained only after receiving consent from the aforementioned user or organization. If the user chooses to refuse, the process proceeds to an expert decision-making process.

[0035] This invention proposes a recording and playback software testing method based on a simulation system. The recording and playback technology can be used to trace the execution process of the program to find the root cause of errors and anomalies. By recording the system's operations, security vulnerabilities can be audited and analyzed. Furthermore, by recording the system's runtime performance data, the system's performance can be monitored and analyzed to identify performance bottlenecks and optimize them.

[0036] The automated testing technology proposed in this invention can automate testing tasks by simulating keyboard and mouse operations. This technology features recording / playback / loop execution functions, helping users quickly complete repetitive tasks. Through combinatorial analysis (combined testing) and the Pairwise algorithm, test case sets can be generated based on multi-factor combined testing to cover all combinations of values ​​for any N factors. This allows for the discovery of defects caused by the combined effect of N factors; that is, each parameter only needs to be paired with each other parameter at least once to achieve full test coverage.

[0037] The recording and playback technology of the simulation system proposed in this invention supports the rapid generation of single-application test cases through recording, with 100% assertion coverage of transaction fields. This improves the efficiency of test case maintenance and overcomes the dependence of playback on the environment and data, enabling the automatic formation of external dependency barriers, thus enhancing the stability and reliability of playback results. Through recording and playback technology, automated testing can be effectively executed, saving labor costs, accelerating testing speed, and improving software quality and stability.

[0038] The present invention will now be described in detail with reference to various embodiments.

[0039] Example 1

[0040] According to an embodiment of this application, an embodiment of a software testing method is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0041] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a software testing method is shown. Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions may also be included. In addition, it may include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera, wherein the network interface can be connected to wired and / or wireless networks. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0042] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0043] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the software testing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned software testing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0044] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0045] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0046] Under the aforementioned operating environment, this application provides the following: Figure 2 The software testing method shown. Figure 2 This is a flowchart of a software testing method according to Embodiment 1 of the present invention, as follows: Figure 2 As shown, the method includes the following steps:

[0047] Step S201: Initiate a transaction process recording request in the original transaction system to obtain test data. The original transaction system refers to the system in which the financial institution is currently executing the transaction process.

[0048] In this embodiment of the invention, test operations can be performed in the test environment of the original trading system to initiate a trading process. A recording tool can then be used to record the user's actions and system events, including input operations, button clicks, and page navigation. The recorded transaction information is then saved in a specific format, such as a script file or log file, to obtain test data for subsequent playback.

[0049] Here, the original trading system refers to the host system currently running by the financial institution, which is used to execute the trading process.

[0050] Step S202: Based on the test data, generate test cases for multiple transaction dimensions, wherein each test case includes at least the expected output.

[0051] In this embodiment of the invention, based on the recorded test data, a Pairwise algorithm is used to generate test cases for multiple transaction dimensions. Here, the Pairwise algorithm is a combined testing strategy that ensures that all possible combinations of any two parameters are tested at least once, thereby reducing the total number of test cases and improving testing efficiency. The generated test cases cover multiple dimensions of the transaction process, including different transaction types, amount amounts, account status, and time points, ensuring the comprehensiveness and depth of the testing.

[0052] In this embodiment of the invention, "transaction dimension" refers to various parameters or conditions that affect the transaction process, such as transaction amount, account type, operation time, etc. "Expected output" is the system response result preset for each input and operation condition according to the transaction logic and rules, and is the standard for evaluating the correctness of the test script execution result.

[0053] Step S203: Based on all test cases, construct test scripts.

[0054] In this embodiment of the invention, an automated testing framework and language can be used to transform the generated test cases into specific code logic, forming executable test scripts. The scripts include instructions for simulating user operations, API calls, data submissions, and page redirects, ensuring that each test case can be executed automatically and that the software's behavior and performance can be accurately evaluated.

[0055] Step S204: Run the test script on the software to be tested to obtain the test output corresponding to each test case, and generate a test report based on the expected output and test output corresponding to each test case.

[0056] In this embodiment of the invention, the constructed test script is deployed to the software environment to be tested (such as a new platform system), and the test script is run to execute test cases. During the execution of the test script, the actual test output can be automatically recorded, and then compared and analyzed with the corresponding expected output to identify any inconsistencies or errors. Finally, a detailed test report is generated, which lists the test results, the problems found, and the suggested improvement measures.

[0057] In summary, by employing a recording and playback approach, comprehensive test data is obtained by initiating a recording request for the transaction process within the original trading system. Based on this data, a Pairwise algorithm (a combined testing algorithm) is used to generate test cases covering multiple transaction dimensions. Furthermore, an automated test script is built upon these test cases. This script runs automatically on the software under test, providing real-time test output for each test case. By comparing the expected output with the actual test output for each test case, a detailed test report is automatically generated. This not only improves testing efficiency and coverage but also effectively reduces labor costs, ensuring the stability and reliability of the trading system after migration to a new platform. Ultimately, this solves the technical problem that manual testing struggles to cover all scenarios under large-scale transaction data and complex transaction types, impacting software quality and user experience.

[0058] To improve the accuracy of the test data, in the software testing method provided in Embodiment 1 of this application, a test environment is created on the original transaction system; a pre-set transaction process is executed on the test environment; during the execution of the transaction process, a recording tool is used to record the execution operations of the transaction process to obtain test data, wherein the execution operations include at least: user operations and system event operations.

[0059] In this embodiment of the invention, a closed and controllable test environment can be established on the host system (i.e., the original transaction system). This environment simulates actual transaction scenarios as closely as possible, including but not limited to all functional modules, user interface, database environment, and network configuration of the transaction system. This ensures that transaction processes can be securely executed and recorded, and test data collected, without affecting real business operations. Once the test environment is ready, a series of transaction processes can be designed according to requirements and functional specifications. These processes cover different types of transactions, such as transfers, deposits, loan applications, etc., as well as various anomalies and boundary conditions. By executing these pre-defined transaction processes in the test environment using automated tools, the system's functions and performance can be comprehensively tested to simulate real user operations and detect the behavior and response of the transaction system under various normal and abnormal conditions, thereby ensuring the system's stability and security.

[0060] In this embodiment of the invention, a recording tool can be used to monitor and record all relevant execution operations while the transaction process is being executed. These operations include at least user actions (such as filling out forms and clicking buttons) and system event operations (such as page loading, data submission, API calls, and error handling). The recording tool captures and saves detailed information about these operations, including input data, operation time, operation results, and system state changes, ultimately forming test data.

[0061] In this embodiment, a test environment that matches the functionality of the original trading system can be systematically created and utilized to perform comprehensive trading process tests. Test data of all relevant operations can be efficiently recorded using recording tools. This not only helps ensure the functionality, compatibility, and performance of the trading system, but also significantly reduces testing costs and shortens the testing cycle, thereby accelerating the migration process of the host system to the new platform and ensuring the stable operation of the new platform and the user experience.

[0062] To improve the accuracy of generating test cases for multiple transaction dimensions, the software testing method provided in Embodiment 1 of this application determines multiple transaction dimensions based on the transaction scenario of the transaction process executed by the original transaction system; based on test data, it determines the input, expected output, and execution flow under each transaction dimension, wherein the execution flow includes: multiple operations from input to expected output and the execution relationship between each operation; for each transaction dimension, test cases for the transaction dimension are generated based on the input, expected output, and execution flow under the transaction dimension.

[0063] In this embodiment of the invention, the transaction scenarios of the transaction process can be determined first, including but not limited to transfers, deposits, loan approvals, and account inquiries. Then, based on these scenarios, key parameters or conditions affecting the transaction process, i.e., transaction dimensions, can be identified. Examples include transaction type, transaction amount, account status, operation time, and network environment. This ensures that test cases comprehensively cover all aspects of the transaction process, detecting potential single-factor and interaction-factor defects. Next, based on test data, the specific inputs (such as user-inputted amount, password, account information, etc.), expected outputs (such as successful transaction, account balance update, error messages, etc.), and execution flow (i.e., the entire processing from input to output, including user interface operations, data processing logic, and system response) under each transaction dimension can be analyzed. Through these analyses, the testing points for each dimension can be clarified, generating highly targeted test cases. Then, for each determined transaction dimension, a Pairwise algorithm is used to generate test cases based on the inputs, expected outputs, and execution flow. Here, the Pairwise algorithm ensures that any combination of two transaction parameters is tested at least once, thereby significantly reducing the total number of test cases while maintaining sufficient test coverage. The generated test cases will provide a detailed description of how to simulate user operations, how to verify system responses, and the expected output results, in order to facilitate the writing and execution of subsequent automated test scripts.

[0064] In this embodiment, starting from actual transaction scenarios, transaction dimensions can be accurately determined, and test cases covering all dimensions can be efficiently generated based on test data. This not only improves testing efficiency and accuracy but also significantly reduces the workload of manually designing test cases, effectively ensuring transaction stability, data consistency, and continuity of user experience during the migration of the host system to a new platform. Furthermore, by employing combined testing strategies such as the Pairwise algorithm, complex defects caused by parameter interactions can be further discovered, improving software quality.

[0065] To improve the accuracy of test script construction, in the software testing method provided in Embodiment 1 of this application, all test cases are sorted based on the transaction dimension to obtain a sorting result; based on the sorting result, a combination testing algorithm is used to traverse all test cases to determine whether there are identical test cases, where identical test cases refer to test cases with the same input and the same expected output; if identical test cases exist, new test cases corresponding to the new transaction dimension are generated based on the transaction dimension corresponding to the identical test cases, and the identical test cases are replaced with the new test cases to obtain a target test case set; test combinations are constructed, and test scripts are constructed based on the target test case set and the test combinations, where the test combination is a combination used to test all test cases.

[0066] In this embodiment of the invention, all generated test cases can be sorted according to determined transaction dimensions (such as transaction type, amount, account status, etc.). For example, they can be sorted according to the importance, risk level, or impact on system functionality coverage of the transaction dimensions. Then, according to the sorting results, each test case is checked one by one using a combination testing algorithm (such as the Pairwise algorithm) to identify whether there are two or more test cases with completely identical inputs and expected outputs. This eliminates redundancy and avoids repeatedly executing the same or similar tests during the testing process, thereby improving overall testing efficiency. If identical test cases are found during the traversal, the transaction dimensions corresponding to these test cases are analyzed to determine new transaction dimensions. By adjusting input parameters or introducing new test conditions, more diverse test cases are generated to ensure that all transaction dimensions and their combinations are fully tested. After the replacement is completed, the resulting set of test cases without redundancy and with comprehensive coverage is used as the target test case set.

[0067] In this embodiment of the invention, since each determined transaction dimension is orthogonal (i.e., none of the transaction dimensions overlap), and most software defects are caused by a single factor or the interaction of two factors, with a small portion caused by the interaction of three factors, software testing can be performed based on a test case set that covers all interactions of two factors. Therefore, when constructing test combinations, each test combination can include level values ​​corresponding to any two test factors. By constructing multiple test combinations, it can be ensured that the level value of each test factor can be tested, i.e., all combinations of level values ​​for any two factors can be tested. Then, based on the target test case set and test combinations, automated test scripts are developed.

[0068] In this embodiment, the constructed test scripts cover as many transaction scenarios and different transaction types as possible within the host system, including transaction interface display, compatibility, data submission judgment, page redirection, and message sending and receiving. Furthermore, the constructed test scripts consider the implementation of code logic, front-end interface calls, middleware caching and forwarding of data, asynchronous data processing by scheduled task scripts, and inter-program calls. Vulnerabilities such as database connection failures, missing fields in tables, incorrect field definitions, duplicate data, field length limitations, and data dictionary mismatches can be located using database tools and basic database query statements, traversing as many tables, fields, and even values ​​as possible.

[0069] In this embodiment, the test case set is effectively streamlined, redundancy is eliminated, and the comprehensiveness and depth of testing are ensured. Furthermore, the test scripts constructed by the optimized test case set and test combinations can achieve efficient and high-coverage testing of the software within limited time and resources, thereby improving the efficiency of software testing, reducing manpower costs, and promoting the improvement of software quality. This provides solid technical support for the stable migration of the system and the smooth launch of the new platform.

[0070] To improve the accuracy of constructing test combinations, in the software testing method provided in Embodiment 1 of this application, multiple test factors are determined based on the transaction scenario of the transaction process executed by the original trading system; the level value corresponding to each test factor is determined; and each level value corresponding to all test factors is arbitrarily combined in pairs to obtain multiple test combinations.

[0071] In this embodiment of the invention, test factors to be tested can be determined based on the transaction scenario of the transaction process. For example, for a transfer transaction scenario, test factors could include checking the validity of the account or checking the correctness of the password. Then, for each test factor, its possible value range, i.e., level values, is listed. For example, for the factor of checking the validity of the account, the level value can include valid or invalid. Afterwards, all level values ​​of each test factor are arbitrarily paired to generate a series of test combinations, ensuring that each pair of test factor level values ​​is tested at least once, thereby reducing the total number of test cases while maintaining high test coverage. Through this intelligent combination, the focus can be placed on the scenarios most likely to reveal software defects, rather than blindly pursuing comprehensive testing.

[0072] In this embodiment, by accurately determining the test factors and their level values, and employing an efficient combination strategy (such as the Pairwise algorithm), a test combination is generated that covers key points of the transaction process while avoiding excessive resource consumption. This not only improves testing efficiency and reduces labor costs, but also ensures that the software has undergone thorough testing before migrating to the new platform, reducing instability and potential risks after deployment.

[0073] To improve the accuracy of determining the test output corresponding to each test case, in the software testing method provided in Embodiment 1 of this application, all test cases are deployed in a test environment on the software under test; test scripts are run in the test environment through a simulation system to replay all test cases by calling each test combination; a recording tool is used to record the replay process of each test case to obtain replay data, and the performance data of the software under test is recorded during the replay of test cases; based on the replay data, the test output corresponding to each test case is determined.

[0074] In this embodiment of the invention, test cases can be deployed in a test environment on the software under test, such as a server, cloud platform, mobile device, or embedded system. A suitable deployment method can be selected based on the environment, such as deployment via Web API (Web Application Programming Interface), mobile application, or edge computing. During simulation system playback testing, a recording tool can be used to load recording files and simulate user operations or system events to execute the recorded content, thus simulating the same test process as the host system. During playback, the software's behavior and performance can be monitored, the actual results compared with the expected results during recording, and platform system logs and host transaction logs can be analyzed to verify the software's correctness and stability.

[0075] Specifically, all test cases can be deployed in the test environment on the software under test. During deployment, it is ensured that the test cases are compatible with the software environment, including software version, database structure, network configuration, etc., to facilitate subsequent test script execution. After the test cases are deployed, an automated test script is loaded and executed using a simulation system. The script contains the calling instructions for all test combinations, simulating user operations and system events in the test environment, and replaying each test case one by one. This process, conducted through a simulation system, ensures a high degree of similarity between the test environment and the production environment, thereby improving the reliability and predictability of the test results. While the test script is running, a recording tool is used to record the complete execution flow of each test case, including key information such as user interface operations, data submission, and system responses, forming replay data. In addition, the performance data of the software under test, such as response time, resource consumption, and concurrency processing capabilities, should also be monitored and recorded simultaneously to evaluate the software's performance under various transaction conditions. Subsequently, by analyzing the replay data, the actual output result of each test case is determined, i.e., the software's performance when executing that test case. By comparing the actual output with the expected output, identifying the differences or defects, and generating a detailed test report, we can guide further optimization of the software.

[0076] In this embodiment, by deploying and executing automated test scripts in the test environment and using a simulation system to fully replay the test combination, not only are the functions and performance of the software under test efficiently verified, but detailed replay data is also collected through recording tools, providing strong support for subsequent test report generation and software optimization.

[0077] To improve the accuracy of the generated test report, the software testing method provided in Embodiment 1 of this application determines whether the expected output and the test output corresponding to each test case are consistent. If there is a discrepancy between the expected output and the test output corresponding to a test case, a replay failure is identified, and the cause of the failure is located based on the log data of the simulation system. The input parameters during the replay of the target test case are obtained, and the call parameter status of the software under test is determined based on the input parameters. Here, the target test case refers to the test case where the expected output and the test output are inconsistent. The performance status of the software under test is determined based on performance data. A test report is generated based on the cause of failure, the call parameter status, and the performance status.

[0078] In this embodiment of the invention, problems during the playback process can be analyzed, including functional defects and performance issues, and promptly reported to the development team for repair. If transaction data successfully recorded on the host system fails to play back on the simulation platform, the error logs of the simulation system can be checked first to quickly locate the problem. Packet capture tools can also be used to check whether the parameters passed to the backend interface during replay are consistent with those previously entered. For example, if numbers were entered previously, but the interface requires strings, then the problem lies with the frontend parameter passing. Based on the recording and playback results and feedback, the recorded content can be continuously adjusted and optimized to improve the efficiency and accuracy of recording and playback.

[0079] Specifically, after replaying all test cases, the expected output of each test case can be automatically compared with the actual test output. If the expected output of a test case is found to be inconsistent with the actual test output, the replay is considered a failure. At this point, the log data generated by the simulation system during the execution of that test case can be reviewed. The log data includes software runtime status information, error messages, operation records, etc. By analyzing this information, the cause of the failure can be gradually investigated, which may include software logic errors, data processing anomalies, external interface call failures, timeouts caused by performance bottlenecks, etc. Furthermore, for the test case that failed to replay, i.e., the target test case, all parameters passed to the software during the replay process can be extracted. Subsequently, by reviewing the status of these parameters, including their type, format, and value range, it can be checked whether there are any improper handling or unforeseen situations, which may be the direct causes of test failure. For example, if a parameter should be an integer but a non-integer value is passed in the test, it may trigger the software's exception handling mechanism, causing the test output to be inconsistent with expectations. While identifying software defects, the software's performance status can also be monitored. By analyzing performance data recorded during test case execution, such as response time, CPU utilization, and memory usage, the software's efficiency and stability under specific loads can be evaluated. Then, combining the reasons for failures, step call parameter status, and performance status, a comprehensive test report can be generated. The report details all failed test cases, the specific reasons for failure (including software logic errors, data processing anomalies, performance bottlenecks, etc.), suggested remedial measures, and an overall performance assessment of the software.

[0080] In this embodiment, defects and anomalies in the software during playback testing can be effectively identified and located, while a comprehensive assessment of the software's performance status is conducted, providing strong data support and guidance for subsequent software optimization and system upgrades. This not only strengthens software quality control and reduces deployment risks but also promotes iterative improvements in software development and increases work efficiency.

[0081] The software testing method provided in this application obtains comprehensive test data by initiating a transaction process recording request in the original trading system. Based on this test data, a Pairwise algorithm (combined testing algorithm) is used to generate test cases covering multiple transaction dimensions. An automated test script is then constructed based on these test cases. This script can automatically run on the software under test, obtaining real-time test output for each test case. By comparing the expected output with the actual test output for each test case, a detailed test report is automatically generated. This not only improves testing efficiency and coverage but also effectively reduces labor costs, ensuring the stability and reliability of the trading system after migration to a new platform. Furthermore, it solves the technical problem that manual testing struggles to cover all scenarios under large-scale transaction data and complex transaction types, impacting software quality and user experience.

[0082] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0083] Example 2

[0084] This application also provides a software testing apparatus. It should be noted that the software testing apparatus of this application can be used to execute the software testing method provided in this application. The software testing apparatus provided in this application is described below.

[0085] According to an embodiment of this application, an apparatus for implementing the above-described software testing method is also provided. Figure 3 This is a schematic diagram of an optional software testing apparatus according to an embodiment of the present invention, such as... Figure 3 As shown, the software testing device may include: an initiation unit 30, a generation unit 31, a construction unit 32, and a running unit 33.

[0086] The initiating unit 30 is used to initiate a transaction process recording request in the original transaction system to obtain test data. The original transaction system refers to the system in which the financial institution is currently executing the transaction process.

[0087] The generation unit 31 is used to generate test cases for multiple transaction dimensions based on test data, wherein each test case includes at least: expected output;

[0088] Building unit 32 is used to build test scripts based on all test cases;

[0089] The execution unit 33 is used to run test scripts on the software under test, obtain the test output corresponding to each test case, and generate a test report based on the expected output and test output corresponding to each test case.

[0090] The software testing apparatus provided in this application adopts a recording and playback method. By initiating a recording request for the transaction process in the original trading system, comprehensive test data is obtained. Then, based on this test data, a Pairwise algorithm (combined testing algorithm) is used to generate test cases covering multiple transaction dimensions. Based on these test cases, an automated test script is constructed. This script can automatically run on the software under test, obtaining real-time test output corresponding to each test case. By comparing the expected output of each test case with the test output, a detailed test report is automatically generated. In this way, not only is testing efficiency and coverage improved, but labor costs are also effectively reduced, ensuring the stability and reliability of the trading system after migration to a new platform. This solves the technical problem that manual testing is difficult to cover all scenarios under large-scale transaction data and complex transaction types, affecting software quality and user experience.

[0091] Optionally, the initiating unit includes: a first creation module for creating a test environment on the original trading system; a first execution module for executing a pre-set trading process on the test environment; and a first recording module for recording the execution operations of the trading process using a recording tool to obtain test data, wherein the execution operations include at least: user operations and system event operations.

[0092] Optionally, the generation unit includes: a first determining module, used to determine multiple transaction dimensions based on the transaction scenario of the transaction process executed by the original transaction system; a second determining module, used to determine the input, expected output, and execution process under each transaction dimension based on test data, wherein the execution process includes: multiple operations from the input to the expected output and the execution relationship between the operations; and a first generation module, used to generate test cases for each transaction dimension based on the input, expected output, and execution process under the transaction dimension.

[0093] Optionally, the construction unit includes: a first sorting module, used to sort all test cases based on the transaction dimension to obtain a sorting result; a first judgment module, used to traverse all test cases using a combination testing algorithm based on the sorting result to determine whether there are identical test cases, wherein identical test cases refer to test cases with the same input and the same expected output; a second generation module, used to generate new test cases corresponding to the new transaction dimension based on the transaction dimension corresponding to the identical test cases when identical test cases exist, and replace the identical test cases with the new test cases to obtain a target test case set; and a first construction module, used to construct test combinations and construct test scripts based on the target test case set and the test combinations, wherein the test combination is a combination used to test all test cases.

[0094] Optionally, the first construction module includes: a first determining submodule, used to determine multiple test factors based on the trading scenario of the trading process executed by the original trading system; a second determining submodule, used to determine the level value corresponding to each test factor; and a first combining submodule, used to arbitrarily combine each level value corresponding to all test factors in pairs to obtain multiple test combinations.

[0095] Optionally, the execution unit includes: a first deployment module for deploying all test cases in a test environment on the software under test; a first execution module for running test scripts in the test environment through a simulation system to replay all test cases by calling each test combination; a second recording module for recording the replay process of each test case using a recording tool to obtain replay data, and recording the performance data of the software under test during the replay of test cases; and a third determination module for determining the test output corresponding to each test case based on the replay data.

[0096] Optionally, the running unit further includes: a second judgment module, used to judge whether the expected output and test output corresponding to each test case are consistent; a first location module, used to determine the replay failure when there is a discrepancy between the expected output and test output corresponding to a test case, and to locate the cause of failure based on the log data of the simulation system; a first acquisition module, used to acquire the input parameters during the replay of the target test case, and to determine the calling parameter status of the software under test based on the input parameters, wherein the target test case refers to the test case where the expected output and test output are inconsistent; a fourth determination module, used to determine the performance status of the software under test based on performance data; and a third generation module, used to generate a test report based on the cause of failure, the calling parameter status, and the performance status.

[0097] The aforementioned software testing device may also include a processor and a memory. The aforementioned initiation unit 30, generation unit 31, construction unit 32, and running unit 33 are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0098] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, test scripts are run on the software under test, obtaining the test output for each test case. Based on the expected and actual outputs for each test case, a test report is generated.

[0099] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0100] It should be noted that the aforementioned initiating unit 30, generating unit 31, building unit 32, and running unit 33 correspond to steps S201 to S204 in Embodiment 1. The instances and application scenarios implemented by the aforementioned units and their corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the aforementioned units may be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The aforementioned units may also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0101] Example 3

[0102] Embodiments of this application may provide an electronic device. Figure 4 This is a structural block diagram of an electronic device according to an embodiment of the present invention. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (Only one is shown) Processor 402, memory 404, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0103] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the software testing method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the aforementioned software testing method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0104] The processor can access information and applications stored in memory via a transmission device to perform the following steps: create a test environment on the original trading system; execute a pre-set trading process on the test environment; and record the execution operations of the trading process using a recording tool to obtain test data, wherein the execution operations include at least: user operations and system event operations.

[0105] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Based on the transaction scenario of the original transaction system's execution flow, determine multiple transaction dimensions; based on test data, determine the input, expected output, and execution flow for each transaction dimension, wherein the execution flow includes: multiple operations from input to expected output and the execution relationships between these operations; for each transaction dimension, generate test cases for that transaction dimension based on the input, expected output, and execution flow.

[0106] The processor can access information and applications stored in memory via a transmission device to execute the following steps: Sort all test cases based on transaction dimensions to obtain a sorting result; based on the sorting result, use a combinatorial testing algorithm to traverse all test cases and determine if there are identical test cases, where identical test cases refer to test cases with the same input and the same expected output; if identical test cases exist, generate new test cases corresponding to the new transaction dimensions based on the transaction dimensions corresponding to the identical test cases, and replace the identical test cases with the new test cases to obtain a target test case set; construct test combinatorials, and based on the target test case set and test combinatorials, construct test scripts, where the test combinatorials are combinations used to test all test cases.

[0107] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: based on the trading scenario of the trading process executed by the original trading system, determine multiple test factors; determine the level value corresponding to each test factor; and arbitrarily combine each level value corresponding to all test factors in pairs to obtain multiple test combinations.

[0108] The processor can access information and applications stored in memory via a transmission device to perform the following steps: deploy all test cases in a test environment on the software under test; run test scripts in the test environment using a simulation system to replay all test cases by calling each test combination; record the replay process of each test case using a recording tool to obtain replay data, and record the performance data of the software under test during the replay of test cases; and determine the test output corresponding to each test case based on the replay data.

[0109] The processor can access information and applications stored in memory via a transmission device to perform the following steps: determine whether the expected output and test output for each test case are consistent; if there is a discrepancy between the expected output and test output for a test case, determine that the replay has failed, and locate the cause of the failure based on the simulation system's log data; obtain the input parameters during the replay of the target test case, and determine the call parameter status of the software under test based on the input parameters, where the target test case refers to the test case where the expected output and test output are inconsistent; determine the performance status of the software under test based on performance data; and generate a test report based on the cause of failure, the call parameter status, and the performance status.

[0110] This application provides a software testing solution. It employs a recording and playback method, initiating a recording request for the transaction process in the original trading system to obtain comprehensive test data. Based on this test data, a Pairwise algorithm (a combined testing algorithm) is used to generate test cases covering multiple transaction dimensions. Based on these test cases, an automated test script is constructed. This script can automatically run on the software under test, obtaining real-time test output for each test case. By comparing the expected output with the actual output of each test case, a detailed test report is automatically generated. This not only improves testing efficiency and coverage but also effectively reduces labor costs, ensuring the stability and reliability of the trading system after migration to a new platform. It thus solves the technical problem that manual testing is insufficient to cover all scenarios under large-scale transaction data and complex transaction types, affecting software quality and user experience.

[0111] Those skilled in the art will understand that Figure 4The structure shown is for illustrative purposes only. Electronic devices can also be terminal devices such as smartphones, tablets, PDAs, and mobile internet devices (MIDs). Figure 4 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0112] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0113] Example 4

[0114] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the software testing method provided in Embodiment 1.

[0115] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0116] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing software testing method steps.

[0117] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0118] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0119] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0120] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0121] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0122] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0123] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A software testing method, characterized in that, include: Initiate a transaction process recording request in the original transaction system to obtain test data. The original transaction system refers to the system currently used by the financial institution to execute transaction processes. Based on the test data, test cases for multiple transaction dimensions are generated, wherein each test case includes at least: expected output; Based on all the test cases, construct the test script; Run the test script on the software under test to obtain the test output corresponding to each test case, and generate a test report based on the expected output and the test output corresponding to each test case.

2. The software testing method according to claim 1, characterized in that, The steps to initiate a transaction process recording request in the original trading system and obtain test data include: Create a test environment on the original trading system; Execute the pre-set transaction process on the test environment; During the execution of the transaction process, a recording tool is used to record the execution operations of the transaction process to obtain the test data. The execution operations include at least: user operations and system event operations.

3. The software testing method according to claim 1, characterized in that, The steps for generating test cases across multiple transaction dimensions based on the test data include: Based on the transaction scenario of the transaction process executed by the original transaction system, multiple transaction dimensions are determined; Based on the test data, the input, the expected output, and the execution process are determined for each transaction dimension. The execution process includes multiple operations from the input to the expected output and the execution relationship between the operations. For each transaction dimension, test cases for that transaction dimension are generated based on the input, the expected output, and the execution flow under that transaction dimension.

4. The software testing method according to claim 1, characterized in that, Based on all the test cases, the steps to build the test scripts include: Based on the aforementioned transaction dimension, all the aforementioned test cases are sorted to obtain the sorting results; Based on the sorting results, a combined testing algorithm is used to traverse all the test cases to determine whether there are identical test cases. The identical test cases refer to test cases that have the same input and the same expected output. In the case of the existence of the same test cases, based on the transaction dimension corresponding to the same test cases, generate new test cases corresponding to the new transaction dimension, and replace the same test cases with the new test cases to obtain the target test case set; Construct a test suite, and based on the target test case set and the test suite, construct the test script, wherein the test suite is a combination used to test all test cases.

5. The software testing method according to claim 4, characterized in that, The steps to build a test portfolio include: Based on the trading scenario executed by the original trading system, multiple test factors are determined. Determine the level value corresponding to each of the test factors; For each level value corresponding to all the test factors, any pairwise combination is performed to obtain multiple test combinations.

6. The software testing method according to claim 1, characterized in that, The steps of running the test script on the software under test to obtain the test output corresponding to each test case include: Deploy all the test cases in the test environment on the software under test; The test script is run in the test environment using a simulation system to replay all the test cases by calling each test combination; The playback process of each test case is recorded using a recording tool to obtain playback data, and the performance data of the software under test is recorded during the playback of the test cases. Based on the replay data, the test output corresponding to each test case is determined.

7. The software testing method according to claim 6, characterized in that, The step of generating a test report based on the expected output and the test output corresponding to each test case includes: Determine whether the expected output and the test output for each test case are consistent. If the expected output and the test output corresponding to the test case are inconsistent, the playback is determined to be a failure, and the cause of the failure is located based on the log data of the simulation system. The input parameters during the replay of the target test case are obtained, and the call parameter status of the software under test is determined based on the input parameters. The target test case refers to the test case where the expected output and the test output are inconsistent. Based on the performance data, the performance status of the software under test is determined; The test report is generated based on the failure reason, the call parameter status, and the performance status.

8. A software testing apparatus, characterized in that, include: The initiating unit is used to initiate a transaction process recording request in the original transaction system to obtain test data. The original transaction system refers to the system in which the financial institution is currently executing the transaction process. A generation unit is configured to generate test cases for multiple transaction dimensions based on the test data, wherein each test case includes at least: expected output; A building unit is used to build test scripts based on all the test cases described. The execution unit is used to run the test script on the software under test, obtain the test output corresponding to each test case, and generate a test report based on the expected output and the test output corresponding to each test case.

9. A computer program product, characterized in that, The method includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the software testing method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the software testing method according to any one of claims 1 to 7.

Images