System testing method and device

By obtaining and parsing the target log to generate test messages, the time-consuming and labor-consuming problem of manually writing packets in system testing is solved, and efficient test coverage and cost reduction is achieved.

CN114218106BActive Publication Date: 2024-12-20CCB FINTECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202111544374.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-12-16
Publication Date
2024-12-20
Estimated Expiration
2041-12-16

AI Technical Summary

Technical Problem

During the system testing process, a large number of test messages need to be written manually, which leads to high time and manpower consumption, high testing costs, and many verification scenarios for complex systems, making it difficult to complete the full test within a specified time, and there is a risk of insufficient verification.

Method used

By obtaining the target log of the system under test, analyzing the request message, determining the field to be parameterized, and setting it as scene data, generating the message to be tested, using the message to be tested for testing, reducing manual intervention and improving testing efficiency.

Benefits of technology

It realizes automatic generation of test packets based on the test scenario, reduces test time and labor consumption, reduces test costs, and improves test coverage and system verification accuracy.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114218106B_ABST
    Figure CN114218106B_ABST
Patent Text Reader

Abstract

The present invention discloses a system testing method and device, and relates to the technical field of system testing. A specific implementation of the method includes: obtaining a target log of a system under test; obtaining a request message of the system under test according to the target log; determining a field to be parameterized in the request message, wherein the field to be parameterized is a field corresponding to a test scenario of the system under test; setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario; and using the message to be tested to test the system under test. This implementation can automatically generate corresponding test messages according to the test scenario, reduce time and manpower consumption, and reduce testing costs.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of system testing, and in particular to a system testing method and device. Background Art

[0002] System testing is a process used to identify the correctness, integrity, security and quality of a system. When testing a system, you often encounter a variety of complex test scenarios. To ensure the comprehensiveness of the test, you need to manually write a large number of test messages, which consumes a lot of time and manpower, resulting in high testing costs. Summary of the invention

[0003] In view of this, an embodiment of the present invention provides a system testing method and device, which can automatically generate corresponding test messages according to the test scenario, reduce the consumption of time and manpower, and reduce the testing cost.

[0004] In a first aspect, an embodiment of the present invention provides a system testing method, including:

[0005] Get the target log of the system under test;

[0006] Obtaining a request message of the system under test according to the target log;

[0007] Determine a field to be parameterized in the request message, where the field to be parameterized is a field corresponding to a test scenario of the system under test;

[0008] Setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario;

[0009] The system under test is tested using the message to be tested.

[0010] Optionally, obtaining a target log of the system under test includes:

[0011] Obtaining log capture conditions, wherein the log capture conditions include at least one of the following: a transaction date condition, a log identification condition, a contract number condition, and a transaction status condition;

[0012] According to the log capture condition, the target log is obtained from the transaction log of the system to be tested.

[0013] Optionally, setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test includes:

[0014] Performing variable processing on the request message, wherein the variable processing is used to set the to-be-parameterized field in the request message to a preset variable;

[0015] Determine a field parameter value table of the test scenario, wherein the field parameter value table includes at least one of the scenario data;

[0016] A message to be tested of the system under test is generated according to the request message after the variable processing and the field parameter value table.

[0017] Optionally, the determining of the field parameter value table of the test scenario includes:

[0018] Obtaining a transaction log of the system to be tested;

[0019] The values ​​of the fields to be parameterized in the transaction log are extracted to generate a field parameter value table for the test scenario.

[0020] Optionally, extracting the value of the field to be parameterized in the transaction log to generate a field parameter value table of the test scenario includes:

[0021] Extracting the value of the field to be parameterized in the transaction log and generating an original parameter value table;

[0022] The original parameter values ​​are subjected to data cleaning processing to generate a field parameter value table for the test scenario.

[0023] Optionally, generating the message to be tested of the system under test according to the request message after the variable processing and the field parameter value table includes:

[0024] Obtaining a target value from the field parameter value table;

[0025] The preset variable in the request message after the variable processing is replaced with the target value to generate a message to be tested of the system under test.

[0026] Optionally, generating the message to be tested of the system under test according to the request message after the variable processing and the field parameter value table includes:

[0027] The field to be parameterized is used as an associated field, and the request message after the variable processing and the field parameter value table are associated to generate a message to be tested of the system under test.

[0028] Optionally, the testing the system under test by using the message to be tested includes:

[0029] Sending the message to be tested to the system under test by using a simulated transmitter or a preamble system;

[0030] Obtaining a processing result of the system under test;

[0031] A test result of the system under test is determined according to the processing result.

[0032] Optionally, determining a test result of the system under test according to the processing result includes:

[0033] matching the processed result with the expected result;

[0034] If the processing result matches the expected result, determining that the system under test passes the test;

[0035] In the event that the processing result does not match the expected result, it is determined that the system under test has failed the test.

[0036] In a second aspect, an embodiment of the present invention provides a system testing device, including:

[0037] The log acquisition module is used to obtain the target log of the system under test;

[0038] A message obtaining module, used to obtain a request message of the system under test according to the target log;

[0039] A field determination module, used to determine a field to be parameterized in the request message, wherein the field to be parameterized is a field corresponding to a test scenario of the system under test;

[0040] A data setting module, used for setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario;

[0041] The testing module is used to test the system under test by using the message to be tested.

[0042] Optionally, the log acquisition module is specifically used to:

[0043] Obtaining log capture conditions, wherein the log capture conditions include at least one of the following: a transaction date condition, a log identification condition, a contract number condition, and a transaction status condition;

[0044] According to the log capture condition, the target log is obtained from the transaction log of the system to be tested.

[0045] Optionally, the data setting module is specifically used to:

[0046] Performing variable processing on the request message, wherein the variable processing is used to set the to-be-parameterized field in the request message to a preset variable;

[0047] Determine a field parameter value table of the test scenario, wherein the field parameter value table includes at least one of the scenario data;

[0048] A message to be tested of the system under test is generated according to the request message after the variable processing and the field parameter value table.

[0049] In a third aspect, an embodiment of the present invention provides an electronic device, including:

[0050] one or more processors;

[0051] a storage device for storing one or more programs,

[0052] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments.

[0053] In a fourth aspect, an embodiment of the present invention provides a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the above embodiments.

[0054] In a fifth aspect, an embodiment of the present invention provides a computer program product, including a computer program, which implements the method described in any of the above embodiments when executed by a processor.

[0055] An embodiment of the above invention has the following advantages or beneficial effects: according to the target log of the system under test, a request message of the system under test is obtained. The field to be parameterized in the request message is set to the scenario data, and the field to be parameterized is a field corresponding to the test scenario of the system under test. According to the scenario to be tested, the field to be parameterized in the request message can be set to different scenario data to generate a corresponding test message, and the system under test is tested using the test message to obtain the test result of the system under test. Therefore, the scheme of the embodiment of the present invention can automatically generate the corresponding test message according to the test scenario, reduce the time and manpower consumption required for the test process, and reduce the test cost.

[0056] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0058] Figure 1 is a flowchart of a system testing method provided by the first embodiment of the present invention;

[0059] Figure 2 is a flow chart of a system testing method provided by the second embodiment of the present invention;

[0060] Figure 3 is a flow chart of log collection provided by the third embodiment of the present invention;

[0061] Figure 4 It is a flowchart of a message processing method provided by the third embodiment of the present invention;

[0062] Figure 5 is a structural schematic diagram of a system testing device provided by an embodiment of the present invention;

[0063] Figure 6 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0064] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0065] When online transactions are being tested in application assembly or user verification, for some complex backend clearing and settlement systems, the following problems may occur during the manual testing process:

[0066] Many verification scenarios: For example, for financial system applications, there are many initiation channels, many products, and many business characteristic parameters. There may be omissions in case design, and even if they are well designed, it may be difficult to complete all tests within the specified time due to the large number of cases, short test cycle, insufficient testers, etc., not to mention multiple full-volume regression verifications.

[0067] High reliance on the stability of each test system: For complex systems, in the actual testing process, they also rely on the functional stability of the previous system or module. When the above situation occurs, only some of the most important scenarios can be selected for verification. There is a risk of insufficient verification of important background system modules, and the probability of production problems after going online will also be relatively high.

[0068] Based on this, an embodiment of the present invention provides a system testing method, which can automatically generate corresponding test messages according to the test scenario. Figure 1 is a flow chart of a system testing method provided by the first embodiment of the present invention, such as Figure 1 As shown, the method includes:

[0069] Step 101: Obtain the target log of the system under test.

[0070] The target log can be all or part of the transaction log of the system under test. The log capture condition can be obtained first, and the log capture condition includes at least one of the following: transaction date condition, log identification condition, contract number condition and transaction status condition. Then, according to the log capture condition, the target log is obtained from the transaction log of the system under test. The transaction status is the relevant status of the transaction in the system under test. The transaction status may include: success, failure, suspension, etc. The user can first set the log capture condition according to the needs, and the background program will capture the target log that matches the log capture condition from the transaction log of the system under test according to the log capture condition.

[0071] Step 102: Obtain a request message of the system under test according to the target log.

[0072] According to the network protocol and the composition structure of the target log, the target log can be parsed to obtain the fields corresponding to the request message in the log, thereby parsing the request message from the target log.

[0073] Step 103: Determine the field to be parameterized in the request message, where the field to be parameterized is a field corresponding to the test scenario of the system under test.

[0074] The field to be parameterized is the field corresponding to the test scenario of the system under test. Different test scenarios correspond to different fields to be parameterized. For example, if the system under test is a financial system, and the test scenario is related verification for multiple channels, the field to be parameterized can be a channel identifier. By setting different channel identifiers in the request message, the multiple channels corresponding to the request message are set. For another example, if the system under test is a financial system, and the test scenario is related verification for multiple currencies, the field to be parameterized can be a currency identifier. By setting different currency identifiers in the request message, the multiple currencies corresponding to the request message are set.

[0075] Step 104: setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario.

[0076] Scenario data is the value corresponding to the test scenario. Different test scenarios correspond to different scenario data. For example, if the system under test is a financial system and the test scenario is related verification for multiple channels, the scenario data can be: business outlets, telephone banking, online banking, self-service banking, etc. For another example, if the system under test is a financial system and the test scenario is related verification for multiple currencies, the scenario data can be: RMB, USD, JPY, HKD, etc.

[0077] It should be noted that, in order to facilitate system storage, the scenario data can also be the identifier of the value corresponding to the test scenario. For example, for various channels, the system sets 1 to identify the business outlets, 2 to identify the telephone bank, 3 to identify the online bank, 4 to identify the self-service bank, etc. The scenario data can be: 1, 2, 3, 4, etc.

[0078] Step 105: Use the message to be tested to test the system under test.

[0079] The message to be tested can be sent to the system under test by using a simulated transmitter or a preamble system; the processing result of the system under test is obtained; and the test result of the system under test is determined according to the processing result. Specifically, the processing result is matched with the expected result; if the processing result matches the expected result, it is determined that the system under test has passed the test; if the processing result does not match the expected result, it is determined that the system under test has failed the test.

[0080] The simulation transmitter can be selected according to specific needs, such as jmeter, LR, etc. The preamble system is a system set up at the front end of the system under test. The system under test uses the output of the preamble system as input. During the test process, sometimes the test data cannot be normally input into the system under test due to the failure of the preamble system. Therefore, using the simulation transmitter to send test messages to the system under test can reduce the impact of the preamble system on the test process, and the test efficiency will be further improved.

[0081] In an embodiment of the present invention, a request message of the system under test is obtained according to the target log of the system under test. The field to be parameterized in the request message is set to the scenario data, and the field to be parameterized is a field corresponding to the test scenario of the system under test. According to the scenario to be tested, the field to be parameterized in the request message can be set to different scenario data to generate a corresponding test message, and the system under test is tested using the test message to obtain the test result of the system under test. Therefore, the scheme of the embodiment of the present invention can automatically generate the corresponding test message according to the test scenario, reduce the time and manpower consumption required for the test process, and reduce the test cost.

[0082] Figure 2 is a flow chart of a system testing method provided by the first embodiment of the present invention, such as Figure 2 As shown, the method includes:

[0083] Step 201: Obtain the target log of the system under test.

[0084] Step 202: Obtain a request message of the system under test according to the target log.

[0085] Step 203: Determine the field to be parameterized in the request message, where the field to be parameterized is a field corresponding to the test scenario of the system under test.

[0086] Step 204: Perform variable processing on the request message, wherein the variable processing is used to set the to-be-parameterized fields in the request message as preset variables.

[0087] Preset variables can be set according to specific needs. Preset variables can be: Va1Dt, SYS_EVT-TRACE, ${Txn_Dt}, etc. It should be noted that the preset variables cannot be the same as or conflict with the original variables, constants and other names in the system.

[0088] Step 205: Determine a field parameter value table of the test scenario, wherein the field parameter value table includes at least one of the scenario data.

[0089] For example, the system under test is a financial system, and the test scenario is related verification for multiple channels. Common channels involved include: business outlets, telephone banking, online banking, self-service banking, etc. For various channels, the system sets 1 to identify business outlets, 2 to identify telephone banking, 3 to identify online banking, 4 to identify self-service banking, etc., and the scenario data can be: 1, 2, 3, 4, etc. Then the field parameter value table may include: business outlets, telephone banking, online banking, self-service banking, etc. Alternatively, the field parameter value table may also include: 1, 2, 3, 4, etc.

[0090] Step 206: Generate a message to be tested of the system under test according to the request message after the variable processing and the field parameter value table.

[0091] At least one target value is obtained from the field parameter value table, and the target value is used to replace the request message after the variable processing to generate at least one message to be tested.

[0092] Step 207: Use the message to be tested to test the system under test.

[0093] In the embodiment of the present invention, the field to be parameterized in the request message is first set to a preset variable, and then the variableized request message is replaced with the target value in the field parameter value table to generate at least one message to be tested. The generated message to be tested can correspond to various situations of the test scenario.

[0094] In one embodiment of the present invention, the determining of the field parameter value table of the test scenario includes: obtaining a transaction log of the system to be tested; extracting the value of the field to be parameterized in the transaction log to generate the field parameter value table of the test scenario. The target value in the field parameter value table is used to replace the variableized request message to generate the message to be tested.

[0095] In one embodiment of the present invention, the extracting the values ​​of the fields to be parameterized in the transaction log to generate the field parameter value table of the test scenario includes: extracting the values ​​of the fields to be parameterized in the transaction log to generate the original parameter value table; performing data cleaning processing on the original parameter values ​​to generate the field parameter value table of the test scenario. Data cleaning processing includes checking data consistency, processing invalid values ​​and missing values, etc. Through data cleaning processing, the data quality of the test data can be improved, making the final test results more accurate.

[0096] In one embodiment of the present invention, generating the message to be tested of the system under test according to the request message after the variable processing and the field parameter value table includes: obtaining a target value from the field parameter value table; replacing the preset variable in the request message after the variable processing with the target value to generate the message to be tested of the system under test. The above scheme is applicable to the case of generating a single test message.

[0097] In one embodiment of the present invention, the generating of the test message of the system under test according to the request message after the variable processing and the field parameter value table includes: taking the field to be parameterized as the associated field, performing association processing on the request message after the variable processing and the field parameter value table to generate the test message of the system under test. The above scheme is applicable to the situation where multiple test messages are generated at the same time. For example, the field parameter value table may also include: 1, 2, 3, 4, then 4 test messages can be obtained after the association processing, and the fields to be parameterized in the 4 test messages are 1, 2, 3, 4 respectively.

[0098] The formats of some application log files are relatively fixed. A method can be used to automatically identify and intercept manually executed successful transaction logs based on the number that can uniquely locate successful transactions (for example, global tracking number, contract number, etc.), to form the request message required by the system under test, and to perform variable processing on the fields to be parameterized in the same type of message in the form of batch replacement, so that they are automatically associated with the field parameter value table of the business combing. This is to achieve the purpose of deriving a variety of rich test scenarios from a single message. At the same time, combined with the use of simulation senders such as jmeter or LR, simulating transaction requests to be sent to the system under test can quickly reduce dependence on the previous system and better solve problems such as incomplete case coverage, single scenario instantiation, long verification cycle, and high investment cost.

[0099] Based on the above analysis, for some application log file formats that are relatively fixed, an embodiment of the present invention provides a collection and processing tool that can automatically capture system logs and generate test messages. The collection and processing tool is explained below.

[0100] Install the collection and processing tool in the application user of the system under test, and adjust the application log level (the message information can be fully output). Provide a configuration file according to the agreed syntax specifications (see the subsequent tool instructions for details). After the front-end business personnel complete the first business processing, centrally register the number information that can uniquely locate the successful transaction (for example: contract number, global tracking number, etc.). Manually trigger the execution of the processing tool, and through simple interactive operations, you can achieve the effects of specified log collection, message log business field variable conversion, and business data extraction with the same service code but different business scenarios (manifested in different business field values). In conjunction with the previous message log business field variable processing, it can quickly form the effect of simulating request messages (partial field parameterization) + instantiation data required for parameterization in the subsequent automated testing process, and can be imported into the simulation test platform for subsequent regression testing. The collection and processing tool can achieve the following functions:

[0101] Function 1: Batch capture log request messages according to the processing list. Figure 3 FIG. 1 is a flow chart of a log collection process provided by the third embodiment of the present invention. Figure 3As shown, the log collection process includes: reading the list of batch intercepted messages and determining whether the list file exists. If the list file does not exist, a prompt message "the batch interception list file does not exist" is issued and the system exits. If the list file exists, determine whether the list file is empty. If the list file is empty, a prompt message "the batch interception list file is empty, please check" is issued and the system exits. If the list file is not empty, obtain the name of the folder for the batch intercepted messages, and check whether the batch intercepted message folder exists. If the batch intercepted message folder does not exist, create a new folder with the corresponding name. If the batch intercepted folder exists, a prompt is given that the folder with the corresponding name already exists. Batch intercept the logs of the specified path and save them to the intercepted message folder.

[0102] Capture target logs in batches, based on key information of unique fields in the specified list, such as transaction date, contract number, etc. It is generally used for bulk message capture and subsequent playback purposes after the application functions are relatively stable). The target log needs to include: the first field and the second field. The data in the corresponding column of the first field mainly corresponds to the value that can uniquely locate the message. The data in the corresponding column of the second field is mainly the transaction execution date. Pay attention to the format of log volume in the system. Each system may have slight differences. Check the date format under this user. Note: Some application logs will be saved in volumes according to date and size of about 50M.

[0103] Place the captured request message file or target log file in the folder you just entered. You can name the file as follows: service code_transaction record number_forward system transaction number_global tracking number.log capture date.

[0104] Function 2: Capture request messages for a single transaction based on the transaction date and contract number entered. Capture XML messages for a single transaction based on the transaction date and contract number. (Generally used in the single transaction testing phase when the application system function is not yet stable).

[0105] Function 3: Replace the values ​​of fields in the intercepted messages with the specified variable names. Replace the values ​​of fields in the specified list with the specified values. (Mainly used for parameterized variable replacement of field values). Figure 4 FIG. 1 is a flow chart of a method for processing a message provided by the third embodiment of the present invention. Figure 4As shown, the message processing method includes: reading the batch interception list file, determining the date information (stored in the e_date variable) and the unique keyword (stored in the t_id field) corresponding to the batch interception list file. Set the path of the MSG log folder to be intercepted. According to the above variables, form a combined keyword to search for the log file where the corresponding log falls (note the search order of the volume log), and determine whether the log file corresponding to the combined keyword is found. If the log file corresponding to the combined keyword is not found, a prompt message "No relevant log file is found, please confirm the input" is issued and exit. If the log file corresponding to the combined keyword is found, a prompt message "The corresponding log file is found in the XX file" is issued. According to the list keyword, the single-layer line number that matches the feature string is marked in the found log file and output to temporary file 1. According to the list keyword, the single-layer line number that matches the feature string is marked in the found log file and output to temporary file 2. Anchor point positioning and fragment processing are performed on temporary file 1 and temporary file 2. Intercept the file according to the starting and ending line numbers, splice according to the specified string, and save it to the folder entered previously.

[0106] Function 4: Extract parameterized data in batches from intercepted messages. According to the field names in the specified list, extract the corresponding field values ​​of all files in the directory to generate parameterized files. (Mainly used to assign values ​​to variables in function 3).

[0107] The field values ​​in the parameterized file are separated by |. You can use FTP to get the file locally and use Excel to import it to generate an Excel file. Import the above materials into the interface automation test platform for automated test verification. Later, you can check a single case to execute in the interface automation test platform, or you can check the directory to execute in batches.

[0108] The embodiment of the present invention can quickly process the logs generated by manual testing through the collection and processing tool. Converting them into the materials required for automation, that is, parameterized messages with variables and parameterized files, can save manpower in the production of manual automation cases to a certain extent. Through simple manual processing, it can be converted into a script that can be recognized by the interface automation tool, so that the subsequent interface-based regression test or pre-data embedding of specific tests can be realized, such as: report type testing, performance stress testing, accounting testing, testing of different parameter types, etc. (to save the time of technical personnel to find logs, meet the large-scale coverage of functional test paths, and improve the efficiency of test data embedding, etc.).

[0109] In the scheme of the embodiment of the present invention, the request message data can be quickly obtained. In the existing testing process, technicians need to retrieve error information or check the correctness of related business data processing, and often use manual methods to flip logs. Since logs are stored in volumes according to date and size, there are certain problems of difficulty in retrieval and time-consuming and labor-intensive. The collection and processing tool provided by the embodiment of the present invention can quickly capture messages within a specified range in single or batch form through a simple interface interaction method for subsequent processing and analysis.

[0110] In addition, it can also achieve rapid accumulation of automation materials. After the functional testing is relatively stable, the tool's functions can be used in the manual testing process to quickly form automated testing assets (request messages and parameterized data). Through simple operations, it can quickly form interface automation cases that can be recognized by industry automation tools, thereby achieving the purpose of subsequent automation assets.

[0111] In addition, the implementation and implementation cost of the solution of the embodiment of the present invention is low. By using the tool to automatically intercept and parameterize batches of messages and load them into the head office integrated test platform or Jmeter, LoaderRunner tools, it can be used as a supplement to functional testing and pre-test data to a certain extent. It improves the coverage of test verification and reduces the cost of test implementation.

[0112] Figure 5 is a schematic diagram of the structure of a system testing device provided by an embodiment of the present invention, such as Figure 5 As shown, the device comprises:

[0113] The log acquisition module 501 is used to acquire the target log of the system under test;

[0114] A message obtaining module 502 is used to obtain a request message of the system under test according to the target log;

[0115] A field determination module 503 is used to determine a field to be parameterized in the request message, where the field to be parameterized is a field corresponding to a test scenario of the system under test;

[0116] A data setting module 504 is used to set the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario;

[0117] The testing module 505 is used to test the system under test using the message to be tested.

[0118] Optionally, the log acquisition module 501 is specifically used for:

[0119] Obtaining log capture conditions, wherein the log capture conditions include at least one of the following: a transaction date condition, a log identification condition, a contract number condition, and a transaction status condition;

[0120] According to the log capture condition, the target log is obtained from the transaction log of the system to be tested.

[0121] Optionally, the data setting module 504 is specifically used to:

[0122] Performing variable processing on the request message, wherein the variable processing is used to set the to-be-parameterized field in the request message to a preset variable;

[0123] Determine a field parameter value table of the test scenario, wherein the field parameter value table includes at least one of the scenario data;

[0124] A message to be tested of the system under test is generated according to the request message after the variable processing and the field parameter value table.

[0125] Optionally, the data setting module 504 is specifically used to:

[0126] Obtaining a transaction log of the system to be tested;

[0127] The values ​​of the fields to be parameterized in the transaction log are extracted to generate a field parameter value table for the test scenario.

[0128] Optionally, the data setting module 504 is specifically used to:

[0129] Extracting the value of the field to be parameterized in the transaction log and generating an original parameter value table;

[0130] The original parameter values ​​are subjected to data cleaning processing to generate a field parameter value table for the test scenario.

[0131] Optionally, the data setting module 504 is specifically used to:

[0132] Obtaining a target value from the field parameter value table;

[0133] The preset variable in the request message after the variable processing is replaced with the target value to generate a message to be tested of the system under test.

[0134] Optionally, the data setting module 504 is specifically used to:

[0135] The field to be parameterized is used as an associated field, and the request message after the variable processing and the field parameter value table are associated to generate a message to be tested of the system under test.

[0136] Optionally, the testing module 505 is specifically used for:

[0137] Sending the message to be tested to the system under test by using a simulated transmitter or a preamble system;

[0138] Obtaining a processing result of the system under test;

[0139] A test result of the system under test is determined according to the processing result.

[0140] Optionally, the testing module 505 is specifically used for:

[0141] matching the processed result with the expected result;

[0142] If the processing result matches the expected result, determining that the system under test passes the test;

[0143] In the event that the processing result does not match the expected result, it is determined that the system under test has failed the test.

[0144] An embodiment of the present invention provides an electronic device, including:

[0145] one or more processors;

[0146] a storage device for storing one or more programs,

[0147] When one or more programs are executed by one or more processors, the one or more processors implement the method of any of the above embodiments.

[0148] An embodiment of the present invention provides a computer program product, including a computer program. When the computer program is executed by a processor, the method of any of the above embodiments of the present invention is implemented.

[0149] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present invention. Figure 6 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0150] like Figure 6As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0151] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0152] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are executed.

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

[0154] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0155] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor, for example, they may be described as: a log acquisition module, a message acquisition module, a field determination module, a data setting module, and a test module. The names of these modules do not, in some cases, constitute limitations on the modules themselves, for example, the log acquisition module may also be described as a "module for acquiring the target log of the system under test".

[0156] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes:

[0157] Get the target log of the system under test;

[0158] Obtaining a request message of the system under test according to the target log;

[0159] Determine a field to be parameterized in the request message, where the field to be parameterized is a field corresponding to a test scenario of the system under test;

[0160] Setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario;

[0161] The system under test is tested using the message to be tested.

[0162] According to the technical solution of the embodiment of the present invention, a request message of the system under test is obtained according to the target log of the system under test. The field to be parameterized in the request message is set to the scenario data, and the field to be parameterized is the field corresponding to the test scenario of the system under test. According to the scenario to be tested, the field to be parameterized in the request message can be set to different scenario data to generate a corresponding test message, and the system under test is tested using the test message to obtain the test result of the system under test. Therefore, the solution of the embodiment of the present invention can automatically generate the corresponding test message according to the test scenario, reduce the time and manpower consumption required for the test process, and reduce the test cost.

[0163] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A system testing method, characterized in that: include: Get the target log of the system under test; Obtaining a request message of the system under test according to the target log; Determine a field to be parameterized in the request message, where the field to be parameterized is a field corresponding to a test scenario of the system under test; Setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario; Using the message to be tested, testing the system under test; The obtaining of the target log of the system under test includes: Obtaining log capture conditions, wherein the log capture conditions include at least one of the following: a transaction date condition, a log identification condition, a contract number condition, and a transaction status condition; According to the log capture condition, obtaining the target log from the transaction log of the system under test; The step of setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test includes: Performing variable processing on the request message, wherein the variable processing is used to set the to-be-parameterized field in the request message to a preset variable; Determine a field parameter value table of the test scenario, wherein the field parameter value table includes at least one of the scenario data; Generate a message to be tested of the system under test according to the request message after the variable processing and the field parameter value table; The field parameter value table for determining the test scenario includes: Obtaining a transaction log of the system under test; The values ​​of the fields to be parameterized in the transaction log are extracted to generate a field parameter value table for the test scenario.

2. The method according to claim 1, characterized in that: The extracting the value of the field to be parameterized in the transaction log to generate a field parameter value table of the test scenario includes: Extracting the value of the field to be parameterized in the transaction log and generating an original parameter value table; The original parameter values ​​are subjected to data cleaning processing to generate a field parameter value table for the test scenario.

3. The method according to claim 1, characterized in that The step of generating a message to be tested of the system under test according to the request message after the variable processing and the field parameter value table comprises: Obtaining a target value from the field parameter value table; The preset variable in the request message after the variable processing is replaced with the target value to generate a message to be tested of the system under test.

4. The method according to claim 1, characterized in that: The step of generating a message to be tested of the system under test according to the request message after the variable processing and the field parameter value table comprises: The field to be parameterized is used as an associated field, and the request message after the variable processing and the field parameter value table are associated to generate a message to be tested of the system under test.

5. The method according to claim 1, characterized in that The step of testing the system under test by using the message to be tested includes: Sending the message to be tested to the system under test by using a simulated transmitter or a preamble system; Obtaining a processing result of the system under test; A test result of the system under test is determined according to the processing result.

6. The method according to claim 5, characterized in that Determining the test result of the system under test according to the processing result includes: matching the processed result with the expected result; If the processing result matches the expected result, determining that the system under test passes the test; In the event that the processing result does not match the expected result, it is determined that the system under test has failed the test.

7. A system testing device, characterized in that: include: The log acquisition module is used to obtain the target log of the system under test; A message obtaining module, used to obtain a request message of the system under test according to the target log; A field determination module, used to determine a field to be parameterized in the request message, wherein the field to be parameterized is a field corresponding to a test scenario of the system under test; A data setting module, used for setting the field to be parameterized in the request message as scenario data to generate a message to be tested of the system under test, wherein the scenario data is a value corresponding to the test scenario; A testing module, used to test the system under test using the message to be tested; The log acquisition module is specifically used for: Obtaining log capture conditions, wherein the log capture conditions include at least one of the following: a transaction date condition, a log identification condition, a contract number condition, and a transaction status condition; According to the log capture condition, obtaining the target log from the transaction log of the system under test; The data setting module is specifically used for: Performing variable processing on the request message, wherein the variable processing is used to set the to-be-parameterized field in the request message to a preset variable; Determine a field parameter value table of the test scenario, wherein the field parameter value table includes at least one of the scenario data; Generate a message to be tested of the system under test according to the request message after the variable processing and the field parameter value table; The data setting module is specifically used for: Obtaining a transaction log of the system under test; The values ​​of the fields to be parameterized in the transaction log are extracted to generate a field parameter value table for the test scenario.

8. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

9. A computer readable medium having a computer program stored thereon, characterized in that When the program is executed by a processor, the method described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.