CN113190461B

CN113190461B - System testing method, device and server

Info

Publication number: CN113190461B
Application number: CN202110576765.XA
Authority: CN
Inventors: 蒋菲; 张兴刚; 徐彩霞; 盛燕芬
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2021-05-26
Filing date: 2021-05-26
Publication date: 2024-04-30
Anticipated expiration: 2041-05-26
Also published as: CN113190461A

Abstract

The specification provides a system testing method, a system testing device and a server. Based on the method, when a second request processing system obtained based on the modification of a first request processing system is specifically tested, a history request log is firstly obtained, and a plurality of history online interface request messages are extracted; then a preset request processing model is called, and test requests meeting the coverage requirement and the typical requirement of the target application scene are screened out based on preset screening rules; then, the first request processing system can be tested by utilizing the test request to obtain a first feedback result; switching the second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result, so that the test of the modified second request processing system can be efficiently and pointedly completed, and whether the second request processing system meets the functional requirement can be accurately determined.

Description

System testing method, device and server

Technical Field

The specification belongs to the technical field of big data, and particularly relates to a system testing method, a system testing device and a server.

Background

Business request processing systems of some large institutions (e.g., banks, shopping websites, etc.) are required to receive and process massive business requests every day.

Currently, with the transformation of host application architecture and the increase of processing requirements, many request processing systems are gradually transformed from original host systems based on centralized deployment to platform systems based on distributed deployment. And a great amount of system tests are generally required to be carried out on the modified service request processing system so as to ensure that the modified service request processing system is stable and effective.

However, the existing system testing method is based on the technical problems that the testing process is complex and complicated, the testing efficiency is low and the testing effect is poor when the modified service request processing system is tested.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

The specification provides a system testing method, device and server, which can efficiently and pertinently complete the functional test of a modified second request processing system, accurately determine whether the second request processing system meets corresponding functional requirements, and obtain a better testing effect.

The embodiment of the specification provides a system testing method, which comprises the following steps:

Acquiring a history request log, and extracting a plurality of history online interface request messages from the history request log;

Invoking a preset request processing model to process the plurality of historical online interface request messages based on a preset screening rule so as to screen out test requests meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene;

Testing a first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request;

Switching a second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request;

and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

In some embodiments, the pre-set request processing model includes a model trained based on XGBoost algorithms.

In some embodiments, the preset screening rules include at least one of: transaction business parameters, transaction amount statistics parameters, transaction scenario parameters, request area parameters.

In some embodiments, the transaction service parameters include: and inquiring the public traffic details and/or inquiring the personal transaction details.

In some embodiments, the transaction scenario parameters include at least one of: a mobile phone banking scene, an online banking scene, a counter scene and a self-service terminal scene.

In some embodiments, testing the first request processing system with the test request to obtain a first feedback result includes:

And calling a simulation request testing tool, simulating downstream equipment to send a corresponding data processing request to a first request processing system according to the testing request, and collecting a processing result generated by the first request processing system based on the data processing request as the first feedback result.

In some embodiments, determining whether the second request processing system meets the functionality requirement based on the first feedback result and the second feedback result includes:

Comparing the first feedback result with the second feedback result, and determining a difference value of the feedback results;

Detecting whether the difference value of the feedback result is smaller than a preset difference threshold value;

And under the condition that the difference value of the feedback result is smaller than a preset difference threshold value, determining that the second request processing system meets the functional requirement.

In some embodiments, after detecting whether the difference value of the feedback result is less than a preset difference threshold, the method further comprises:

Under the condition that the difference value of the feedback result is larger than or equal to a preset difference threshold value, determining that the second request processing system does not meet the functional requirement;

correspondingly, determining an abnormal feedback result from the second feedback result according to the difference value of the feedback result;

Positioning an abnormal interface in the second request processing system according to the abnormal feedback result; and repairing the abnormal interface.

In some embodiments, the method further comprises:

Acquiring an abnormal request characteristic;

Constructing an exception request according to the exception request characteristics and the test request;

Testing the second request processing system by using the abnormal request to obtain a third feedback result;

and determining whether the second request processing system meets the security requirement according to the third feedback result.

In some embodiments, the exception request feature includes at least one of: special symbols, malicious code, SQL instructions, illegal dictionary values, null values, and very long values.

The embodiment of the specification also provides a system testing device, which comprises:

the acquisition module is used for acquiring a history request log and extracting a plurality of history online interface request messages from the history request log;

The calling module is used for calling a preset request processing model to process the plurality of historical online interface request messages based on preset screening rules so as to screen out test requests meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene;

the first test module is used for testing the first request processing system by utilizing the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request;

The second test module is used for switching a second request processing system and testing the second request processing system by utilizing the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request;

And the determining module is used for determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

The embodiments of the present specification also provide a server, including a processor and a memory for storing processor executable instructions, the processor implementing the following when executing the instructions: acquiring a history request log, and extracting a plurality of history online interface request messages from the history request log; invoking a preset request processing model to process the plurality of historical online interface request messages based on a preset screening rule so as to screen out test requests meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene; testing a first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request; switching a second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

The present description also provides a computer-readable storage medium having stored thereon computer instructions that, when executed, implement: acquiring a history request log, and extracting a plurality of history online interface request messages from the history request log; invoking a preset request processing model to process the plurality of historical online interface request messages based on a preset screening rule so as to screen out test requests meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene; testing a first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request; switching a second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

The system testing method, the system testing device and the server provided by the specification can firstly acquire the history request log and extract a plurality of history online interface request messages; then, a preset request processing model is called, and based on preset screening rules, a plurality of historical online interface request messages are processed to screen out test requests meeting coverage requirements and typical requirements of a target application scene; then, the first request processing system can be tested by utilizing the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request; switching the second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is based on distributed deployment and is responsible for processing the online interface request; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result, so that the related test of the modified second request processing system can be efficiently and pointedly completed, whether the second request processing system meets the functional requirement can be accurately determined, and a better test effect can be obtained.

Drawings

In order to more clearly illustrate the embodiments of the present disclosure, the drawings that are required for the embodiments will be briefly described below, in which the drawings are only some of the embodiments described in the present disclosure, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of one embodiment of a system architecture composition employing the system test method provided by the embodiments of the present specification;

FIG. 2 is a flow chart of a system test method provided in one embodiment of the present disclosure;

FIG. 3 is a schematic diagram of the structural composition of a server according to one embodiment of the present disclosure;

FIG. 4 is a schematic diagram of the structural composition of a system testing device according to one embodiment of the present disclosure;

FIG. 5 is a schematic diagram of one embodiment of a system testing method provided by embodiments of the present disclosure, in one example scenario;

FIG. 6 is a schematic diagram of one embodiment of a system testing method provided by embodiments of the present disclosure, in one example scenario;

Fig. 7 is a schematic diagram of an embodiment of a system testing method provided by the embodiments of the present disclosure, in one example scenario.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

The embodiment of the specification provides a system testing method which can be particularly applied to a testing system comprising a plurality of testing servers. Referring specifically to fig. 1, a plurality of test servers may be connected by wired or wireless means to perform specific data interaction.

In this embodiment, the test server may specifically include a background server applied to a side of a test system of a data center of a certain bank, and capable of implementing functions such as data transmission and data processing. Specifically, the test server may be, for example, an electronic device having data operation, storage function and network interaction function. Or the test server may be a software program running in the electronic device that provides support for data processing, storage, and network interactions. In the present embodiment, the number of servers included in the test server is not particularly limited. The test server may be one server, several servers, or a server cluster formed by several servers.

In this embodiment, after the interface of the first request processing system originally responsible for receiving and processing the service data processing request of a certain bank is correspondingly modified to obtain a new second request processing system, a corresponding test needs to be performed on the second request processing system to determine whether the second request processing system meets the functional requirement or not: the primary data processing can be accurately completed in place of the first request processing system.

In this embodiment, the first test server interfaces with the first request processing system. The first request processing system may be specifically understood as a system responsible for receiving and processing a transaction data processing request (for example, an account balance inquiry request, a transaction detail inquiry request, a transfer transaction request, etc.) of the bank before modification. In particular, the first request processing system may be a host system responsible for processing online interface requests based on centralized deployment. Based on the system, the host system can be associated with a plurality of business applications through a plurality of pre-retrofit online interfaces.

In practice, the first test server may obtain a log of historical requests for a preset period of time (e.g., the last 1 month) by accessing the first request processing system. The history request log may specifically record related data such as transaction date, transaction time, holographic monitoring link information, request number, online interface request message, etc. of the massive transaction data related to the bank in the preset time period. Further, the first test server may extract a plurality of history online interface request packets from the history request log; and sending the plurality of historical online interface request messages to a second test server.

The second test server may be deployed with a pre-trained preset request processing model. The preset request processing model can be specifically understood as an identification model which is trained based on XGBoost algorithm in advance and can screen out test requests which simultaneously meet coverage requirements and typical requirements of a target application scene from a plurality of historical online interface request messages based on corresponding preset screening rules.

The preset filtering rule may specifically be rule data recorded with a characteristic parameter used as a filtering basis of a preset request processing model. Specifically, the preset screening rule may be obtained by learning historical data, or may be generated by user definition. The preset screening rule may specifically include the following characteristic parameters: transaction parameters (e.g., inquiry business for public traffic details, inquiry business for personal transaction details, etc.), transaction volume statistics parameters (e.g., transaction amount of a day, etc.), transaction scenario parameters (e.g., cell phone banking scenario, online banking scenario, counter scenario, self-service terminal scenario, etc.), request area parameters (e.g., first city, second city, third city, etc.).

In specific implementation, the second test server may input a plurality of historical online interface request messages into a preset request processing model, and run the preset request processing model. When a preset request processing model specifically operates, key fields in a history online interface request message can be identified, and matching of the key fields is performed according to characteristic parameters recorded in a preset screening rule; thus, the historical online interface request messages meeting the coverage requirement and the typical requirement aiming at banking scenes can be screened out from a plurality of historical online interface request messages to be used as the testing request (which can be also recorded as a core request) meeting the requirements; and storing the test request into a preset request library.

And the third test server responsible for specific test work can acquire a plurality of test requests by querying a preset request library. And testing the first request processing system and the second request processing system by using the test request respectively. The second request processing system may be specifically understood as a modified system responsible for receiving and processing the business data processing request of the bank. In particular, the second request processing system may be a distributed platform system based on distributed deployment and responsible for processing online interface requests. Based on the system, the platform system can be associated with a plurality of business applications through a plurality of modified online interfaces.

When the test is specifically performed, the third test server can call a simulation request test tool to send a corresponding data processing request to the first request processing system according to the test request, and collect a processing result generated by the first request processing system based on the data processing request as the first feedback result, so that the test of the first request processing system can be completed.

Then, the third test server can be switched into the second request processing system by controlling the mode changeover switch; and then calling a simulation request testing tool to simulate downstream equipment to send a corresponding data processing request to a second request processing system according to the testing request, and collecting a processing result generated by the second request processing system based on the data processing request as a second feedback result, so that the testing of the second request processing system can be completed.

Further, the third test server may determine, according to the first feedback result and the second feedback result, whether the second request processing system meets the functional requirement; and generating a corresponding first result report. The first result report is used for representing whether the modified second request processing system meets the functional requirement or not, and whether the corresponding service function which is responsible for the first request processing system before modification can be completely and normally realized or not.

Specifically, the third server may compare the first feedback result and the second feedback result first, and determine a difference value of the feedback results; detecting whether the difference value of the feedback result is smaller than a preset difference threshold value or not; and under the condition that the difference value of the feedback result is smaller than a preset difference threshold value, determining that the second request processing system meets the functional requirement.

Further, the modified second request processing system can be used to replace the original first request processing system to complete the business data processing request related to the bank.

Therefore, the second request processing system after the current transformation can be rapidly detected and determined to be normally applicable to most situations of banking scenes, abnormal online interfaces are not existed, and most data processing requirements can be met.

And on the contrary, under the condition that the difference value of the feedback result is larger than or equal to the preset difference threshold value, determining that the second request processing system does not meet the functional requirement.

Correspondingly, the third server can also determine an abnormal feedback result from the second feedback result according to the difference value of the feedback result; positioning an abnormal interface in the second request processing system according to the abnormal feedback result; and repairing the abnormal interface.

Therefore, the method can quickly detect and determine that the second request processing system after the current transformation is not fully applicable to most situations of banking scenes and has partial abnormal online interfaces; and the abnormal online interface can be accurately positioned according to the feedback result obtained by the test, and the abnormal online interface is subjected to targeted repair processing to obtain a modified second request processing system meeting the requirements.

Referring to fig. 2, an embodiment of the present disclosure provides a system testing method, where the method is specifically applied to a server side. In particular implementations, the method may include the following:

S201: acquiring a history request log, and extracting a plurality of history online interface request messages from the history request log;

S202: invoking a preset request processing model to process the plurality of historical online interface request messages based on a preset screening rule so as to screen out test requests meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene;

S203: testing a first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request;

S204: switching a second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request;

S205: and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

Through the embodiment, the preset request processing model can be utilized to screen out relatively fewer test requests with better coverage and representativeness from the acquired massive historical online interface request messages based on the preset screening rules; and the test request can be used for switching and respectively carrying out related tests on the first request processing system before modification and the second request processing system after modification, so that the functional test on the second request processing system after modification can be efficiently and pointedly completed, whether the second request processing system meets the functional requirement or not can be accurately determined, and a better test effect can be obtained.

In some embodiments, the server may be configured to access the first request processing system, or a corresponding history database, to obtain the history request log. Wherein, the history request log records the related information of the data processing request received and processed by the first request processing system in history.

Specifically, taking a transaction service scenario as an example, the history request log may specifically record related data such as massive transaction data, transaction date of the transaction data, transaction time, holographic monitoring link information, request number, online interface request message, and the like, which are related to the first request processing system in a preset time period in history.

In some embodiments, the server may detect and extract a plurality of online interface request messages from the history request log by retrieving and according to the target field.

Since in the big data processing field, the first request processing system may receive and process a huge number of data processing requests in a certain preset period of time in history, the number of the extracted plurality of historical online interface request messages is also relatively huge. If all the extracted historical online interface request messages are used for testing, larger data processing amount and longer data processing time are required to be consumed. Therefore, it is considered that the data processing request with higher coverage and more typical data processing request can be further screened out from a plurality of huge historical online interface request messages to be used as a test request (also called a core request); therefore, the subsequent functional test with higher coverage and better effect for the system can be efficiently completed by using a relatively smaller number of test requests, consuming less data processing amount and shorter data processing time.

In some embodiments, the first request processing system may be specifically understood as a system responsible for receiving and processing an accessed data processing request before modification. In particular, the first request processing system may be a host system based on a centralized deployment.

In some embodiments, the second request processing system may be specifically understood as a system that is adapted to receive and process an accessed data processing request. In particular, the second request processing system may be a distributed deployment-based platform system.

In some embodiments, the modified second request processing system may be obtained by modifying the first request processing system accordingly.

In some embodiments, the data processing request may be a service request of a different type for different application scenarios. For example, taking a banking scenario as an example, the data processing request may specifically include: account balance inquiry requests, transaction detail inquiry requests, transfer transaction requests, and the like. Of course, the above-listed data processing requests are only illustrative. In specific implementation, the data processing request may further include other types of service requests according to specific application scenarios and processing requirements. The present specification is not limited to this.

In some embodiments, the above-mentioned satisfactory test request may be specifically understood as a data processing request that can meet both a coverage requirement (with higher coverage) and a typical requirement (with better representativeness to data processing requests mainly accessed and processed) for a target application scenario (e.g., banking scenario, etc.).

In some embodiments, the foregoing preset request processing model may be specifically understood as a pre-trained recognition model capable of screening, based on a corresponding preset screening rule, a test request that meets both coverage requirements and typical requirements of a target application scenario from multiple historical online interface request messages.

In some embodiments, the preset filtering rule may specifically be rule data recorded with a characteristic parameter used as a filtering basis of the preset request processing model.

In some embodiments, taking a banking scenario as an example, the preset screening rule may specifically include the following feature parameters: transaction business parameters, transaction amount statistics parameters, transaction scenario parameters, request area parameters, and the like. In addition, the preset screening rule may further include a preset threshold parameter.

In some embodiments, taking banking as an example, the transaction parameters may specifically include: and inquiring the public traffic details easily and/or inquiring the personal transaction details.

The inquiry service for personal transaction details may specifically include inquiry for details of a person such as a living date, a credit card, a payroll, financial, fund, and precious metal. The above-mentioned easy detail inquiry business of public transport can include the inquiry of the details of business users, cash manager, comprehensive account, etc. aiming at enterprises or units.

In some embodiments, taking banking as an example, the transaction scenario parameters specifically include at least one of: a mobile banking scene, an online banking scene, a counter scene, a self-service terminal scene and the like.

The above-mentioned mobile banking scenario may be specifically understood as a scenario in which a mobile banking APP on a mobile phone is used to send a related data processing request. The above internet banking scenario may be specifically understood as a scenario in which a web page on a PC side such as a desktop computer, a platform computer, a notebook computer, etc. is used to access an internet banking and transmit a related data processing request. The counter scene can be understood as a scene of interacting with a counter operator in a business handling hall of a bank and manually handling related data processing. The scenario of the self-service terminal may be specifically understood as a scenario of using self-service devices such as ATM machines, self-service machines, etc. to send related data processing requests.

In some embodiments, the above-mentioned request area parameter may be specifically understood as a geographical location where the data processing request is located when the data processing request is sent, and/or a physical address or an IP address of the terminal device sending the data processing request.

In some embodiments, the transaction amount statistical parameter may specifically include: statistics of transaction amount, statistics of transaction period, and the like.

Through the above embodiment, based on the various and abundant feature parameters included in the preset screening rule, the test request with higher coverage and representativeness can be screened more carefully and accurately.

In some embodiments, before implementation, the server may obtain the preset screening rule by learning and summarizing the historical data. Or the server receives the user-defined characteristic parameters and configures and obtains the corresponding preset screening rules according to the user-defined characteristic parameters and the corresponding template rules.

In some embodiments, the preset request processing model may specifically include a model trained based on XGBoost algorithm. The XGBoost (eXtreme Gradient Boosting) algorithm can be specifically understood as an algorithm which is obtained based on GBDT (Gradient Boosting Decision Tree) improvement, is applied to machine learning, and can efficiently realize GBDT operation and the like.

Through the embodiment, the model obtained based on XGBoost algorithm training is utilized to be matched with a preset screening rule, so that the test request meeting the requirements can be accurately screened out.

In some embodiments, a plurality of historical online interface request messages may be input as model inputs into a preset request processing model, and the preset request processing model may be run. When the preset request processing model specifically operates, the search matching of key fields can be performed on a plurality of historical online interface request messages according to preset screening rules, so that the historical online interface request messages meeting the requirements can be found out, and the model is output and used as the test request.

In some embodiments, prior to implementation, a preset request processing model may be trained as follows: constructing an initial model based on XGBoost algorithm; meanwhile, acquiring a sample online interface request message, setting a corresponding label for the sample online interface request message according to a sample screening rule, and obtaining a marked sample online interface request message; according to a preset dividing rule, a part of sample online interface request messages (for example, accounting for 60%) are divided to be used as training sets, another part of sample online interface request messages (for example, accounting for 20%) are used as test sets, and the rest part of sample online interface request messages (for example, accounting for 20%) are used as verification sets; and carrying out corresponding training, testing and verification on the initial model by sequentially utilizing the training set, the testing set and the verification set to obtain a model meeting the precision requirement, and taking the model as a preset request processing model.

In some embodiments, the testing the first request processing system by using the test request to obtain the first feedback result may include the following when implemented: and calling a simulation request testing tool, simulating downstream equipment to send a corresponding data processing request to a first request processing system according to the testing request, and collecting a processing result generated by the first request processing system based on the data processing request as the first feedback result. So that testing for the first request processing system can be accomplished efficiently.

Through the embodiment, the server can simulate the downstream equipment to send the corresponding data processing request to the first request processing system for testing based on the testing request by using the simulation request testing tool without being called to the real downstream equipment, so that the complexity of the testing process can be effectively simplified, and the testing efficiency is improved; and meanwhile, the influence of the test process on downstream equipment can be reduced.

In some embodiments, after testing for the first request processing system is completed, the second request processing system may be quickly switched to by controlling the switch; and further, the second request processing system can be correspondingly tested under the same test environment.

In some embodiments, the switching the second request processing system and testing the second request processing system with the test request to obtain the second feedback result may include: controlling a change-over switch to change the system to be tested from a first request processing system to a second request processing system; and calling a simulation request testing tool to simulate downstream equipment to send a corresponding data processing request to a second request processing system according to the testing request, and collecting a processing result generated by the second request processing system based on the data processing request as the second feedback result. So that testing for the second request processing system can be accomplished efficiently.

In some embodiments, the determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result may include the following when implemented:

s1: comparing the first feedback result with the second feedback result, and determining a difference value of the feedback results;

S2: detecting whether the difference value of the feedback result is smaller than a preset difference threshold value;

s3: and under the condition that the difference value of the feedback result is smaller than a preset difference threshold value, determining that the second request processing system meets the functional requirement.

According to the embodiment, based on the first feedback result and the second feedback result obtained by the two system tests, whether the realized functional effect is consistent with the first request processing system or can meet the normal working requirement or not can be judged by judging whether the second request processing system is used for replacing the first request processing system to process the main data processing request (for example, an online interface request) accessed in the target application scene, so that whether the second request processing system meets the corresponding functional requirement or not can be accurately determined, and whether the second request processing system is used for replacing the first request processing system to complete the processing of the main data processing request in the target application scene or not can be accurately determined.

In some embodiments, after detecting whether the difference value of the feedback result is smaller than a preset difference threshold, the method may further include the following when implemented: under the condition that the difference value of the feedback result is larger than or equal to a preset difference threshold value, determining that the second request processing system does not meet the functional requirement; correspondingly, determining an abnormal feedback result from the second feedback result according to the difference value of the feedback result; positioning an abnormal interface in the second request processing system according to the abnormal feedback result; and repairing the abnormal interface.

Through the embodiment, the abnormal interface in the second request processing system can be accurately positioned by determining and according to the abnormal feedback result in the second feedback result while determining that the second request processing system is abnormal; and performing targeted repair processing on the abnormal interface, so that a second request processing system meeting the functional requirement can be obtained.

In some embodiments, the method may further include the following when implemented:

s1: acquiring an abnormal request characteristic;

S2: constructing an exception request according to the exception request characteristics and the test request;

s3: testing the second request processing system by using the abnormal request to obtain a third feedback result;

s4: and determining whether the second request processing system meets the security requirement according to the third feedback result.

Through the embodiment, the safety of the second request processing system can be effectively tested by utilizing the characteristics of the test request and the abnormal request and constructing and utilizing the corresponding abnormal request, so that a better test effect is obtained.

In some embodiments, the above-described abnormal request feature may be specifically understood as a feature character capable of reflecting some kind of abnormal request with an offensiveness risk. Before specific implementation, a client acquires a large number of abnormal requests with offensiveness risks by querying an attack request database; and then carrying out clustering processing and feature extraction on the plurality of abnormal requests with the offensiveness risk in sequence to obtain the abnormal request features.

In some embodiments, the exception request feature may specifically include at least one of: special symbols, malicious code, SQL instructions, illegal dictionary values, null values, very long values, etc. Wherein each exception request feature corresponds to a class of exception requests.

Through the embodiment, the characteristics of a plurality of different types of abnormal requests can be utilized, and the abnormal requests with rich types and complete types can be constructed by combining the test requests; and the second request processing system can be subjected to more comprehensive and effective security test by utilizing the abnormal request.

In some embodiments, when an exception request is specifically constructed, the exception request feature may be injected and spliced into a normal test request according to a corresponding request construction rule, so as to obtain a corresponding exception request.

In some embodiments, when constructing exception requests in particular, the exception request features and the test may be utilized in batches to construct exception requests using automation tools, so that a large number of exception requests for performing security tests may be quickly constructed. And then, a simulation request testing tool is called, according to the abnormal request, the simulation downstream equipment sends a corresponding data processing request to a second request processing system, and a processing result generated by the second request processing system based on the data processing request is collected and used as the third feedback result.

In some embodiments, when the method is implemented, whether the second request processing system has security problems such as SQL injection, cross-site script, software fault tolerance and the like can be determined according to the third feedback result; and the second request processing system can be subjected to targeted repair processing aiming at the security problem of the second request processing system, so that the security problem of the second request processing system is eliminated, and the reliability of the second request processing system is improved.

From the above, according to the system testing method provided by the embodiment of the present disclosure, a history request log may be obtained first, and a plurality of history online interface request messages may be extracted; then, a preset request processing model is called, and based on preset screening rules, a plurality of historical online interface request messages are processed to screen out test requests meeting coverage requirements and typical requirements of a target application scene; then, the first request processing system can be tested by utilizing the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request; switching the second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is based on distributed deployment and is responsible for processing the online interface request; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result, so that the test of the modified second request processing system can be efficiently and pointedly completed, whether the second request processing system meets the functional requirement can be accurately determined, and a better test effect can be obtained.

The embodiment of the specification also provides a server, which comprises a processor and a memory for storing instructions executable by the processor, wherein the processor can execute the following steps according to the instructions when being implemented: acquiring a history request log, and extracting a plurality of history online interface request messages from the history request log; invoking a preset request processing model to process the plurality of historical online interface request messages based on a preset screening rule so as to screen out test requests meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene; testing a first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request; switching a second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

In order to more accurately complete the above instructions, referring to fig. 3, another specific server is further provided in this embodiment of the present disclosure, where the server includes a network communication port 301, a processor 302, and a memory 303, and the above structures are connected by an internal cable, so that each structure may perform specific data interaction.

The network communication port 301 may be specifically configured to obtain a history request log, and extract a plurality of history online interface request messages from the history request log.

The processor 302 may be specifically configured to invoke a preset request processing model to process the plurality of historical online interface request messages based on a preset screening rule, so as to screen out a test request meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene; testing a first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request; switching a second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

The memory 303 may be used for storing a corresponding program of instructions.

In this embodiment, the network communication port 301 may be a virtual port that binds with different communication protocols, so that different data may be sent or received. For example, the network communication port may be a port responsible for performing web data communication, a port responsible for performing FTP data communication, or a port responsible for performing mail data communication. The network communication port may also be an entity's communication interface or a communication chip. For example, it may be a wireless mobile network communication chip, such as GSM, CDMA, etc.; it may also be a Wifi chip; it may also be a bluetooth chip.

In this embodiment, the processor 302 may be implemented in any suitable manner. For example, a processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application SPECIFIC INTEGRATED Circuits (ASICs), programmable logic controllers, and embedded microcontrollers, among others. The description is not intended to be limiting.

In this embodiment, the memory 303 may include a plurality of layers, and in a digital system, the memory may be any memory as long as it can hold binary data; in an integrated circuit, a circuit with a memory function without a physical form is also called a memory, such as a RAM, a FIFO, etc.; in the system, the storage device in physical form is also called a memory, such as a memory bank, a TF card, and the like.

The embodiments of the present specification also provide a computer storage medium based on the above system test method, where the computer storage medium stores computer program instructions that when executed implement: acquiring a history request log, and extracting a plurality of history online interface request messages from the history request log; invoking a preset request processing model to process the plurality of historical online interface request messages based on a preset screening rule so as to screen out test requests meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene; testing a first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request; switching a second request processing system, and testing the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request; and determining whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

In the present embodiment, the storage medium includes, but is not limited to, a random access Memory (Random Access Memory, RAM), a Read-Only Memory (ROM), a Cache (Cache), a hard disk (HARD DISK DRIVE, HDD), or a Memory Card (Memory Card). The memory may be used to store computer program instructions. The network communication unit may be an interface for performing network connection communication, which is set in accordance with a standard prescribed by a communication protocol.

In this embodiment, the functions and effects of the program instructions stored in the computer storage medium may be explained in comparison with other embodiments, and are not described herein.

Referring to fig. 4, on a software level, the embodiment of the present disclosure further provides a system testing device, which may specifically include the following structural modules:

The obtaining module 401 may specifically be configured to obtain a history request log, and extract a plurality of history online interface request messages from the history request log;

The calling module 402 may be specifically configured to call a preset request processing model, process the plurality of historical online interface request messages based on a preset screening rule, so as to screen out a test request meeting the requirements; wherein, the test request meets the coverage requirement and the typical requirement of the target application scene;

The first test module 403 may be specifically configured to test the first request processing system by using the test request to obtain a first feedback result; the first request processing system is a host system which is based on centralized deployment and is responsible for processing an online interface request;

The second testing module 404 may be specifically configured to switch the second request processing system, and test the second request processing system by using the test request to obtain a second feedback result; the second request processing system is a platform system which is obtained by modifying the first request processing system and is based on distributed deployment and is responsible for processing an online interface request;

The determining module 405 may be specifically configured to determine whether the second request processing system meets the functional requirement according to the first feedback result and the second feedback result.

It should be noted that, the units, devices, or modules described in the above embodiments may be implemented by a computer chip or entity, or may be implemented by a product having a certain function. For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

From the above, based on the system testing device provided by the embodiment of the present disclosure, the test on the modified second request processing system can be efficiently and pertinently completed, and whether the second request processing system meets the functional requirement can be accurately determined, so as to obtain a better testing effect.

In a specific scenario example, the system testing method provided by the embodiment of the present disclosure may be applied to implement verification of security reliability of the transformed platform system interface based on the backtracking of the production request and the abnormal data rule base, for the banking scenario. The specific implementation process can be referred to as follows.

In this scenario example, an exception database rule base may be built based on production request backtracking, and an online interface verification framework for the corresponding exception request may be constructed. Based on the framework, the safety and reliability of the online interface can be ensured through test verification, and the autonomous controllable requirement is met. Comprising the following steps: firstly, acquiring an existing request log (for example, a history request log) before production is transformed by a production environment host downward-moving distributed platform (for example, a second request processing system), and extracting an online interface request message (for example, a history online interface request message) to be incorporated into a request information base; screening out typical transactions (for example, test requests meeting the coverage requirement and the typical requirement of banking scenes at the same time) according to different dimension screening rules (for example, preset screening rules) and machine learning algorithms (for example, preset request processing models) and incorporating the test requests into a core request information base; through switching control service switching and back switching, simulation verification of consistency of request results before and after the host computer moves down the distributed platform to be modified (so as to perform functional test on the second request processing system) so as to ensure stable operation of production transaction; meanwhile, a request data rule base can be established, and abnormal requests are constructed and transactions are simulated (to perform security tests for the second request processing system) by using request parameters (such as abnormal request characteristics) such as injection illegal values, special values, null values, overlength and the like in the request data rule base.

In particular, referring to fig. 5, the following steps may be included.

Step S1, acquiring a history transaction detail query request log file before the host computer is moved down to the distributed platform for transformation through the production operation and maintenance platform, and automatically packaging and pushing the history transaction detail query request log file to a development and test environment. The request log generally contains transaction date, transaction time, holographic monitoring link information, request number, online interface request message and the like. And extracting an online interface request message from the request log file and incorporating the online interface request message into a request information base. The online interface request message records log type information such as a request interface name, a request channel, a request region, a transaction event number, terminal information and the like of historical detail query transaction, and various custom screening condition information such as a query mode, a query range, an account card number currency and the like.

And step S2, modeling is carried out according to screening rules of different dimensions and a machine learning algorithm, and typical transactions are screened from a request information base to be incorporated into a core request information base. Specifically, first, hierarchical management is carried out on requests by combining with the calling condition of a production interface so as to cover different transaction types libraries, transaction scene libraries, request areas and the like, and modeling is carried out by adopting a machine learning algorithm; and screening out core request messages including personal transaction detail query services (such as sub-service types of a living date, a credit card, a payroll, financial accounting, funds, noble metals and the like), public transportation detail query services (such as sub-service types of a business trip, a cash manager, a comprehensive account and the like), different transaction scenes of mobile banking, online banking, counter, self-service terminals and the like, and different request areas, and including the core request messages into a core request information base.

In step S3, the host computer downshifts the distributed platform and should be further provided with a function switch (e.g., a change-over switch), so that when the platform is unstable or the testing environment is modified and has a defect that is not found, the host computer system (e.g., the first request processing system) is supported to be switched back in time, and further, the continuous availability of the transaction can be ensured. Specifically, in the test environment, a simulation request test tool can be used, and the state of the change-over switch is used for verifying whether the return results of the core requests before and after the host moves down the distributed platform to be transformed are consistent. If the returned results are consistent, the method indicates that the host can be compatible with the historical detail query of the host after the host moves down the distributed platform, and the platform interface service does not add a verification rule and modify screening logic, so that the online interface query request can be stably switched to the distributed platform. If the returned results are inconsistent, the change of the interface logic before and after the host computer moves down the distributed platform can be determined, whether the platform interface service has defects or not can be further analyzed one by one, and targeted repair processing can be carried out according to the needs.

In addition, a request data rule base may be built and stored, for example, by injecting special symbols, malicious codes, SQL instructions, illegal dictionary values, null values, ultralong values, etc. (abnormal request features). The incoming parameters of the core request message may then be replaced in batches using an automated tool to construct different types of exception requests. And then, carrying out test verification based on the abnormal request by a simulation request testing tool, and determining whether safety and reliability problems such as SQL injection, cross-site script, software fault tolerance and the like exist or not by analyzing a returned result.

Based on the above steps, the following 7 large modules are further constructed to automatically realize test verification. Referring to fig. 6, an online interface verification framework based on request backtracking under a platform scenario under a host may specifically include the following structural modules:

Production request acquisition module 1: the method can be used for acquiring a request log before a host computer is arranged on a platform from production operation and maintenance, automatically packaging and pushing the request log to a development test environment by periodically acquiring log files from production, extracting an online interface request message according to a request log keyword, and finally storing the request message in a request information base.

Core request identification module 2: the method can be used for acquiring a production core request message, carrying out feature analysis according to different dimension screening rules and machine learning algorithms, constructing a core request identification model, training an interface request of a request information base through the model, identifying a core request and incorporating the core request into the core request information base.

Environment preparation module 3: the method can be particularly used for providing core request test verification environments before and after the cut-off of a lower platform of a host, and automatically controlling the cut-off to inquire a new platform branch or the cut-off to inquire an original host branch by switching test environment service switches in batches, so that version switching is realized rapidly.

Analog core request module 4: the method can be particularly used for simulating a core request in a test environment, constructing a comparison rule model through transaction codes, transaction states, record numbers, field information, error codes, error prompt information and the like, and comparing whether returned results are consistent before and after platform switch switching under a host. If the conditions are inconsistent, the logic of the front and rear interfaces of the lower platform of the host computer is changed, the reasons are needed to be analyzed one by one and then modified according to the needs, and the operation of the module is needed to be repeated after the program is deployed.

Simulation exception request module 5: the method can be particularly used for simulating abnormal requests to launch interface attacks after the host lower platform cuts streams. Firstly, a request data rule base is established, wherein the request data rule base comprises different types of parameter values, special symbols, malicious codes, SQL instructions, illegal dictionary values, blank values, ultralong values and the like, an automation tool is used for replacing a core request message field value by an orthogonal method, an abnormal request is constructed, and the abnormal request is simulated by a simulation test tool.

Report analysis module 6: the method can be particularly used for analyzing the simulation test results of the request, including whether the platform under the core request host is consistent before and after the tangential flow, and whether the abnormal request has the safety and reliability problems of SQL injection, cross-site script, software fault tolerance and the like.

Based on the above modules, referring to fig. 7, the following automated process flow may be performed:

1) Acquiring production log request 10: the original request log is automatically obtained from the production environment.

2) Parsing the acquisition request message 11: and analyzing the original request log according to the keywords to obtain a request message.

3) Core request identification 12: and constructing an analysis model according to the matching rule and the machine learning algorithm, and calculating and identifying the core request by combining the four dimensions and the weight proportion formula of each item.

4) Incorporating core request library 13: the identified core request is automatically incorporated into a core request library.

5) Host lower platform switch 14: and modifying the front and rear environments of the lower platform of the switching host machine through an automatic trigger switch.

6) Core request batch simulation 15: and the front and back of the host lower platform automatically simulate the core request inquiry through a batch simulator.

7) Consistency comparison 16: and comparing whether the core request simulation query results are consistent or not before and after the lower platform of the host machine through an automation tool.

8) Exception request construct 17: and replacing records of which the core request message field value is an abnormal data rule base by using an orthogonal method through an automation tool, and constructing different types of abnormal requests.

9) Abnormal request batch simulation 18: and automatically simulating abnormal request inquiry through a batch simulator.

10 Report generation 19: and generating a report according to the comparison condition of the core request return results before and after the host lower platform is switched, and sending a reliability test report of the abnormal request message after the host lower platform to a tester by mail.

By the method, the production online interface can be rapidly verified in the scene of the host downward movement distributed platform, the testing efficiency is improved, the testing requirement is rapidly responded, and the stability of the application product is comprehensively guarded. Reference may be made in particular to the conventional test frames shown in table 1 and to a comparison table for tests using the inventive frames.

TABLE 1

Through the scene example, the online interface verification framework based on the backtracking of the production request under the host machine lower platform scene is constructed and used, the production core calling scene can be comprehensively covered, and the upstream and downstream communication is effectively reduced, so that the test efficiency is improved. In addition, the safety and reliability of the online interface of the lower platform of the host can be improved by constructing an abnormal request. Specifically, the frame has mainly the following 3 characteristics: 1, a production core request can be intelligently identified, a production operation and maintenance acquisition request log is abutted, a production upper core request message is identified according to a matching rule and a machine learning algorithm, the production upper core request message is automatically put in storage, a full-automatic maintenance application core request message can fully cover a production core scene, and stable production operation before and after a lower platform of a host machine cuts flow is ensured; 2, an abnormal request can be automatically constructed, and the abnormal request is constructed in batches by using an automatic tool through an abnormal data rule base, so that the safety and stability of a lower platform interface of the host are verified; and 3, the verification of the simulation message and the comparison of the result can be automatically performed, the core request and the abnormal request before and after the lower platform of the host are automatically simulated and inquired through the batch simulator, the test report is generated, the quick verification of the online interface under the scene of the lower platform of the host can be realized without depending on the on-duty of a tester, and the test efficiency is effectively improved.

Although the present description provides method operational steps as described in the examples or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented by an apparatus or client product in practice, the methods illustrated in the embodiments or figures may be performed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment). The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. The terms first, second, etc. are used to denote a name, but not any particular order.

Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller can be regarded as a hardware component, and means for implementing various functions included therein can also be regarded as a structure within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, classes, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

From the above description of embodiments, it will be apparent to those skilled in the art that the present description may be implemented in software plus a necessary general hardware platform. Based on such understanding, the technical solutions of the present specification may be embodied essentially in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and include several instructions to cause a computer device (which may be a personal computer, a mobile terminal, a server, or a network device, etc.) to perform the methods described in the various embodiments or portions of the embodiments of the present specification.

Various embodiments in this specification are described in a progressive manner, and identical or similar parts are all provided for each embodiment, each embodiment focusing on differences from other embodiments. The specification is operational with numerous general purpose or special purpose computer system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Although the present specification has been described by way of example, it will be appreciated by those skilled in the art that there are many variations and modifications to the specification without departing from the spirit of the specification, and it is intended that the appended claims encompass such variations and modifications as do not depart from the spirit of the specification.

Claims

1. A system testing method, comprising:

2. The method of claim 1, wherein the predetermined request processing model comprises a model trained based on XGBoost algorithm.

3. The method of claim 1, wherein the preset screening rules include at least one of: transaction business parameters, transaction amount statistics parameters, transaction scenario parameters, request area parameters.

4. A method according to claim 3, wherein the transaction parameters include: and inquiring the public traffic details and/or inquiring the personal transaction details.

5. A method according to claim 3, wherein the transaction scenario parameters include at least one of: a mobile phone banking scene, an online banking scene, a counter scene and a self-service terminal scene.

6. The method of claim 1, wherein testing the first request processing system with the test request results in a first feedback result, comprising:

7. The method of claim 1, wherein determining whether the second request processing system meets the functionality requirement based on the first feedback result and the second feedback result comprises:

8. The method of claim 7, wherein after detecting whether the difference value of the feedback result is less than a preset difference threshold, the method further comprises:

9. The method according to claim 1, wherein the method further comprises:

Acquiring an abnormal request characteristic;

10. The method of claim 9, wherein the exception request feature comprises at least one of: special symbols, malicious code, SQL instructions, illegal dictionary values, null values, and very long values.

11. A system testing apparatus, comprising:

12. A server comprising a processor and a memory for storing processor-executable instructions, which when executed by the processor implement the steps of the method of any one of claims 1 to 10.

13. A computer storage medium having stored thereon computer instructions which, when executed, implement the steps of the method of any of claims 1 to 10.