Abnormal contract testing method, device, terminal equipment and storage medium

Abstract

The present application is applicable to the field of computer technology, and provides a testing method, device, terminal equipment and storage medium for abnormal contracts, wherein the testing method for abnormal contracts includes: obtaining the contract preset transaction price corresponding to the contract to be tested in the target trading system; sending an order request to the target trading system according to the contract preset transaction price, wherein the order request is used to instruct the target trading system to simulate the transaction process of the contract to be tested based on the contract preset transaction price, and return the transaction status of the contract to be tested generated by the transaction process; if the received transaction status of the contract to be tested is not traded, the contract to be tested is determined to be an abnormal contract. The above scheme improves the testing efficiency of abnormal contracts.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and in particular, relates to a testing method, apparatus, terminal device and storage medium for abnormal contracts. Background Art

[0002] With the rapid development of the securities industry, more and more people are participating in securities trading, resulting in an increasing number of orders in the trading system, and higher and higher requirements for the speed of matching securities trading orders.

[0003] The existing order matching method has changed from the traditional manual bidding method to the highly electronic trading system matching order method. Once the order is matched successfully, a contract can be generated for both parties of the order. Since the highly electronic trading system matches orders to meet the speed of order matching, the number of contracts generated in the trading system is also increasing. In the daily operation of securities trading, it is necessary to confirm that each order can be executed normally (that is, executed at the specified transaction price) to ensure the normal progress of the transaction. Manual testing of abnormal contracts (contracts generated after not being executed at the specified transaction price) not only has high labor costs but also low testing efficiency. Summary of the invention

[0004] The embodiments of the present application provide a method, apparatus, terminal device and storage medium for testing abnormal contracts, which can solve the problem of low efficiency in abnormal contract testing in the prior art.

[0005] A first aspect of an embodiment of the present application provides a method for testing an abnormal contract, the method comprising:

[0006] Obtain the contract preset transaction price corresponding to the contract to be tested in the target trading system;

[0007] Sending an order request to the target trading system according to the preset transaction price of the contract, wherein the order request is used to instruct the target trading system to simulate the transaction process of the contract to be tested based on the preset transaction price of the contract, and return the transaction status of the contract to be tested generated by the transaction process;

[0008] If the received transaction status of the contract to be tested is untransacted, it is determined that the contract to be tested is an abnormal contract.

[0009] Optionally, the testing method further comprises:

[0010] If the transaction status of the contract to be tested is not received within the preset time period, the contract to be tested is determined to be an abnormal contract.

[0011] Optionally, when the number of the contracts to be tested is at least two, sending an order request to the target trading system according to the preset transaction price of the contract includes:

[0012] Traversing all the contracts to be tested, determining the target interface corresponding to each of the contracts to be tested in the target trading system, where different contracts to be tested correspond to different target interfaces;

[0013] For each of the contracts to be tested, an order request is sent to the corresponding target interface in the target trading system.

[0014] Optionally, the testing method further comprises:

[0015] Receive the transaction status of the corresponding contract to be tested returned by each target interface in the target trading system.

[0016] Optionally, after determining that the contract to be tested is an abnormal contract, the testing method further includes:

[0017] A generation instruction and a target file path are sent to the target trading system, wherein the generation instruction is used to instruct the target trading system to generate a test report for the abnormal contract, and the target file path is used to store the test report.

[0018] Optionally, after determining that the contract to be tested is an abnormal contract, the testing method further includes:

[0019] Obtaining a target parameter value of the abnormal contract, where the target parameter value is used to indicate a level of detail of recording contract information in the abnormal contract;

[0020] According to the target parameter value, the contract information in the abnormal contract is stored.

[0021] A second aspect of an embodiment of the present application provides a testing device for an abnormal contract, the testing device comprising:

[0022] The acquisition module is used to obtain the preset transaction price of the contract corresponding to the contract to be tested in the target trading system;

[0023] A request sending module, used to send an order request to the target trading system according to the preset transaction price of the contract, wherein the order request is used to instruct the target trading system to simulate the transaction process of the contract to be tested based on the preset transaction price of the contract, and return the transaction status of the contract to be tested generated by the transaction process;

[0024] The first abnormality determination module is used to determine that the contract to be tested is an abnormal contract if the transaction status of the contract to be tested received is not completed.

[0025] The third aspect of an embodiment of the present application provides a terminal device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the abnormal contract testing method described in the first aspect when executing the computer program.

[0026] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the testing method for abnormal contracts described in the first aspect above.

[0027] A fifth aspect of an embodiment of the present application provides a computer program product, which, when executed on a terminal device, enables the terminal device to execute the method for testing an abnormal contract as described in the first aspect above.

[0028] Compared with the prior art, the embodiment of the present application has the following beneficial effects: the embodiment of the present application first obtains the contract preset transaction price corresponding to the contract to be tested in the target trading system, and then sends an order request to the target trading system according to the contract preset transaction price, wherein the contract preset transaction price is the specified transaction price corresponding to the contract to be tested, that is, the order is placed according to the contract preset transaction price, and the transaction status of the contract to be tested should be completed. At this time, the transaction status of the contract to be tested generated during the transaction returned by the target trading system is received. If the transaction status is not completed, it means that the contract to be tested is an abnormal contract. In this way, abnormal contracts in the target trading system can be automatically tested, which improves the testing efficiency compared to manual testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0030] Figure 1 It is a flowchart of a method for testing an abnormal contract provided in Example 1 of the present application;

[0031] Figure 2 It is a flowchart of a method for testing an abnormal contract provided in Example 2 of the present application;

[0032] Figure 3 It is a structural diagram of a testing device for abnormal contracts provided in Example 3 of the present application;

[0033] Figure 4It is a structural diagram of a terminal device provided in Example 4 of the present application. DETAILED DESCRIPTION

[0034] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0035] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0036] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0037] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0038] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0039] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0040] With the rapid development of information technology and the securities industry, the requirements for core technologies in the financial trading field are also constantly increasing. The existing order matching method has changed from the traditional manual bidding method to the highly electronic trading system matching order method. In the traditional financial transaction process, the buyer and seller of the financial transaction finally reach an agreement through bidding and price negotiation, and then form a transaction. Since the entire transaction process mainly relies on people to execute, it is easy to lead to low efficiency, slow speed and large transaction time restrictions in financial transactions. With the continuous changes of the times, financial transactions have embarked on the road of electronic transactions through the combination of computer technology, making the existing financial transaction process efficient, fast and time-limited. Therefore, electronic transactions have now become the mainstream transaction method in the field of financial transactions.

[0041] However, as the number of traders and transactions increases, the electronic trading system is under increasing pressure. Each transaction order needs to be confirmed and completed normally to ensure the normal progress of the transaction. However, due to the large number of contracts generated by transaction orders, if manual testing of abnormal contracts is arranged, it will not only be costly but also inefficient.

[0042] Therefore, the present application provides a testing method for abnormal contracts, which can send an order request to the target trading system by obtaining the contract preset transaction price corresponding to the contract to be tested in the target trading system, wherein the contract preset transaction price is the specified transaction price corresponding to the contract to be tested, that is, the order is placed according to the contract preset transaction price, and the transaction status of the contract to be tested should be completed. At this time, the transaction status of the contract to be tested generated during the transaction process returned by the target trading system is received. If the transaction status is not completed, it means that the contract to be tested is an abnormal contract. In this way, abnormal contracts in the target trading system can be automatically tested, which improves the testing efficiency compared to manual testing and solves the problem of low efficiency of abnormal contract testing in the prior art.

[0043] It should be understood that the size of the serial numbers of the steps in this embodiment does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0044] In order to illustrate the technical solution of the present application, specific embodiments are provided below.

[0045] Reference Figure 1 , shows a flow chart of a method for testing an abnormal contract provided in Example 1 of the present application. Figure 1 As shown, the test method of the abnormal contract may include the following steps:

[0046] Step 101, obtaining the contract preset transaction price corresponding to the contract to be tested in the target trading system.

[0047] In an embodiment of the present application, to obtain the contract preset transaction price corresponding to the contract to be tested in the target trading system, the list of all contracts to be tested in the target trading system can be first searched from a specified directory or a specified memory library of the target trading system, and then the contract preset transaction prices corresponding to all the contracts to be tested can be obtained based on the found list of all contracts to be tested.

[0048] In the embodiment of the present application, the target trading system may refer to a trading system operated in an actual exchange, or may refer to a trading system independently built by a user and operated in a simulated exchange, wherein the rules for order execution in the simulated exchange are the same as those for order execution in the actual exchange, i.e., the rules for order execution are: if the order is a stock sell order, then the buyer with the higher bid is given priority; if the order is a stock buy order, then the seller with the lower bid is given priority, and if the bids are the same, the seller with the earliest order time is given priority. The contract preset transaction price may refer to the price executed according to the order execution rules, i.e., if the order is a stock sell order, then the contract preset transaction price is the buy price (i.e., the price with the highest bid among the buyers); if the order is a stock buy order, then the contract preset transaction price is the sell price (i.e., the price with the lowest bid among the sellers).

[0049] In a possible implementation, obtaining a preset contract transaction price corresponding to the contract to be tested in the target trading system includes:

[0050] Get the market information corresponding to the contract to be tested;

[0051] According to the market information, determine the preset transaction price of the contract corresponding to the contract to be tested.

[0052] In an embodiment of the present application, the market information corresponding to the contract to be tested includes at least a mapping relationship between the contract to be tested and a preset transaction price of the contract. Obtaining the market information corresponding to the contract to be tested can be loading the market information corresponding to the contract to be tested in the exchange from a designated directory or a designated memory library of the target trading system. Since the market information includes at least a mapping relationship between the contract to be tested and a preset transaction price of the contract (the best bid price or the best ask price), the best bid price or the best ask price corresponding to each contract to be tested in the list can be determined based on the market information.

[0053] For example, it is assumed that the target trading system is a trading system independently built by the user and operated in a simulated exchange. There are multiple contracts to be tested and static market information corresponding to the contracts to be tested (i.e., the mapping relationship between the contracts to be tested and the preset transaction prices of the contracts) in the target trading system. Therefore, the static market information corresponding to the contracts to be tested should first be read from the trading system operated by the simulated exchange, and then the preset transaction prices of the contracts to be tested should be extracted from the static market information corresponding to the contracts to be tested.

[0054] Exemplarily, assuming that the target trading system is a trading system operated in an actual exchange, there are multiple contracts to be tested and dynamic market information corresponding to the contracts to be tested (i.e., bids of all buyers or sellers corresponding to the contracts to be tested) in the target trading. Therefore, the dynamic market information corresponding to the contracts to be tested should first be read from the trading system operated in the actual exchange, and the preset contract transaction price corresponding to the contracts to be tested should be determined according to the order execution rules and the dynamic market information corresponding to the contracts to be tested.

[0055] It should be understood that since the preset transaction price of the contract is the prescribed transaction price corresponding to the contract to be tested, if an order is submitted to the target trading system according to the preset transaction price of the contract, the order will always be executed.

[0056] Step 102: Send an order request to the target trading system according to the preset transaction price of the contract.

[0057] In an embodiment of the present application, an order request is used to instruct the target trading system to simulate the trading process of the contract to be tested based on the preset transaction price of the contract, and return the transaction status of the contract to be tested generated by the trading process. That is, after the target trading system receives the order request sent by the terminal device based on the preset transaction price of the contract, it simulates the trading process of the contract to be tested. There is a real transaction price corresponding to the contract to be tested in the target trading system. By simulating the trading process (i.e., comparing the real transaction price with the preset transaction price of the contract), the transaction status of the contract to be tested can be obtained. After the transaction status of the contract to be tested is obtained, the transaction status of the contract to be tested can be returned to the terminal device.

[0058] For example, the terminal device sends an order request to the target trading system with the contract preset transaction price of 500 yuan. It can be learned that the contract preset transaction price is the first buy price or the first sell price in the target trading system. After receiving the order request, the target trading system obtains the actual transaction price corresponding to the contract to be tested (i.e., the price that needs to be tested manually in daily operations) and simulates the transaction process (comparing the actual transaction price corresponding to the contract to be tested with the contract preset transaction price). If the actual transaction price is the same as the contract preset transaction price, it means that the contract to be tested is traded at the first buy price or the first sell price in the target trading system, and the transaction status of the contract to be tested is concluded; if the actual transaction price is different from the contract preset transaction price, it means that the contract to be tested is not traded at the first buy price or the first sell price in the target trading system, and the transaction status of the contract to be tested is concluded as undealt; after the transaction status of the contract to be tested is obtained, the transaction status of the contract to be tested is returned to the terminal device.

[0059] In a possible implementation, when the number of contracts to be tested is at least two, sending an order request to a target trading system according to a preset transaction price of the contract includes:

[0060] Traverse all the contracts to be tested and determine the target interface corresponding to each contract to be tested in the target trading system. Different contracts to be tested correspond to different target interfaces.

[0061] For each contract to be tested, an order request is sent to the corresponding target interface in the target trading system.

[0062] In an embodiment of the present application, each contract to be tested has a corresponding target interface in the target trading system, and the target interface may refer to a target application program interface. Different target interfaces corresponding to different contracts to be tested may be understood as creating a separate user process for each contract to be tested. Each user process may send an order request to the target trading system according to the preset contract price corresponding to the contract to be tested, that is, send an order request to the corresponding target interface in the target trading system.

[0063] Among them, the order request carries the corresponding contract preset transaction price. For example, for the contract A to be tested, an order request is sent to the target interface corresponding to the contract A to be tested in the target trading system, and the order request carries the contract preset transaction price corresponding to the contract A to be tested.

[0064] In a possible implementation manner, for each contract to be tested, after sending an order request to a corresponding target interface in a target trading system, the process further includes:

[0065] Receive the transaction status of the corresponding contract to be tested returned by each target interface in the target trading system.

[0066] In an embodiment of the present application, the terminal device can continuously monitor whether each target interface has received the transaction status of the corresponding contract to be tested within a preset time period.

[0067] Step 103: If the transaction status of the received contract to be tested is untransacted, it is determined that the contract to be tested is an abnormal contract.

[0068] In the embodiment of the present application, since the order request sent by the terminal device to the target trading system is sent according to the preset transaction price of the contract, when the target trading system simulates the transaction process of the contract to be tested, if the actual transaction price of the contract to be tested is the same as the preset transaction price of the contract (the transaction status of the contract to be tested is completed), it means that the contract to be tested is traded at the first buy price or the first sell price in the target trading system, that is, the contract to be tested is a normal contract. If the actual transaction price of the contract to be tested is different from the preset transaction price of the contract (the transaction status of the contract to be tested is not traded), it means that the contract to be tested is not traded at the first buy price or the first sell price in the target trading system, which violates the order trading rules of the target trading system, that is, the contract to be tested is an abnormal contract, so if the transaction status of the received contract to be tested is not traded, it is determined that the contract to be tested is an abnormal contract.

[0069] In a possible implementation, the testing method further includes:

[0070] If the transaction status of the contract to be tested is not received within the preset time, the contract to be tested is determined to be an abnormal contract.

[0071] In an embodiment of the present application, since the terminal device can continuously monitor whether each target interface has received the corresponding transaction status of the contract to be tested within a preset length, if the transaction status of the contract to be tested is not received, possible reasons include delays or terminations in the communication between the terminal device and the target trading system, and also include abnormalities in the contract to be tested itself, that is, the target trading system becomes unresponsive when simulating the transaction process of the contract to be tested and cannot return the transaction status. At this time, the contract to be tested should be determined to be an abnormal contract and needs to be manually tested again to improve the test accuracy.

[0072] In the embodiment of the present application, the contract preset transaction price corresponding to the contract to be tested in the target trading system is first obtained, and then an order request is sent to the target trading system according to the contract preset transaction price, wherein the contract preset transaction price is the specified transaction price corresponding to the contract to be tested, that is, the order is placed according to the contract preset transaction price, and the transaction status of the contract to be tested should be completed. At this time, the transaction status of the contract to be tested generated during the transaction process returned by the target trading system is received. If the transaction status is not completed, it means that the contract to be tested is an abnormal contract. In this way, abnormal contracts in the target trading system can be automatically tested, which improves the test efficiency compared to manual testing.

[0073] See also Figure 2 , shows a flow chart of a method for testing an abnormal contract provided in the second embodiment of the present application. Figure 2 As shown, the test method of the abnormal contract may include the following steps:

[0074] Step 201, obtaining the contract preset transaction price corresponding to the contract to be tested in the target trading system.

[0075] Step 202: Send an order request to the target trading system according to the preset transaction price of the contract.

[0076] Step 203: If the transaction status of the received contract to be tested is untransacted, it is determined that the contract to be tested is an abnormal contract.

[0077] Steps 201-203 of this embodiment are the same as steps 101-103 of the aforementioned embodiment, and can refer to each other, and will not be described in detail in this embodiment.

[0078] Step 204: Send the generation instruction and the target file path to the target trading system.

[0079] In an embodiment of the present application, the generation instruction is used to instruct the target trading system to generate a test report for the abnormal contract, and the target file path is used to store the test report for the abnormal contract.

[0080] The user can choose whether to generate a test report. The parameters for generating a test report can be configured in the terminal device. If the test report is generated, the target file path needs to be configured to store the test report.

[0081] In a possible implementation, if the test report is not generated when the parameter for whether to generate the test report is set in the terminal device, it is not necessary to send the generation instruction and the target file path to the target trading system.

[0082] Step 205, obtain the target parameter value of the abnormal contract, and store the abnormal information in the abnormal contract according to the target parameter value.

[0083] In an embodiment of the present application, the target parameter value is used to indicate the level of detail of the contract information recorded in the abnormal contract. According to different target parameter values, contract information of different levels of detail can be stored for the abnormal contract.

[0084] Exemplarily, if the target parameter value is 1 (indicating that the level of detail of recorded contract information is the lowest), then the corresponding stored contract information of the abnormal contract may include: contract number and contract name; if the target parameter value is 2 (indicating that the level of detail of recorded contract information is one level higher than the lowest), then the corresponding stored abnormal contract information may include: contract number, contract name and the actual transaction price of the contract.

[0085] It should be understood that the correspondence between the target parameter value and the level of detail of the recorded contract information in the above example is only an example, that is, the correspondence between the target parameter value and the level of detail of the recorded contract information can be configured according to the actual application scenario, and this application does not limit the correspondence between the target parameter value and the level of detail of the recorded contract information.

[0086] In a possible implementation, the testing method further includes:

[0087] Read the configuration file, which is used to configure N parameters in the terminal device, where N is an integer greater than 1.

[0088] Among them, the N parameters may at least include whether to generate a test report, a target file path, a target parameter value, a terminal device user name, and an interval time for sending an order request.

[0089] It should be understood that the N parameters configured in the configuration file may also include other parameters required to be configured in the terminal device, which can be configured according to user needs. The embodiment of the present application does not limit the N parameters configured in the configuration file.

[0090] Compared with Example 1, the embodiment of the present application introduces parameter configuration, which can set the level of detail of the contract in recording abnormal contracts, and can store the test report of the abnormal contract to the target file path, so that users can view the abnormal contracts, which improves the testing efficiency compared to manually testing all contracts to be tested.

[0091] See also Figure 3 , shows a schematic diagram of the structure of a testing device for an abnormal contract provided in Example 3 of the present application. For the sake of ease of explanation, only the parts related to the example of the present application are shown.

[0092] The test device 3 for abnormal contracts may specifically include the following modules:

[0093] An acquisition module 301 is used to acquire a preset contract transaction price corresponding to the contract to be tested in the target trading system;

[0094] The request sending module 302 is used to send an order request to the target trading system according to the preset transaction price of the contract. The order request is used to instruct the target trading system to simulate the transaction process of the contract to be tested based on the preset transaction price of the contract, and return the transaction status of the contract to be tested generated by the transaction process;

[0095] The first abnormality determination module 303 is used to determine that the contract to be tested is an abnormal contract if the transaction status of the received contract to be tested is not completed.

[0096] In the embodiment of the present application, the abnormal contract testing device 3 may further include the following modules:

[0097] The second abnormality determination module is used to determine that the contract to be tested is an abnormal contract if the transaction status of the contract to be tested is not received within a preset time period.

[0098] In the embodiment of the present application, the acquisition module 301 may specifically include the following submodules:

[0099] The market determination submodule is used to obtain the market information corresponding to the contract to be tested, and the market information at least includes the mapping relationship between the contract to be tested and the preset transaction price of the contract;

[0100] The price determination submodule is used to determine the preset transaction price of the contract corresponding to the contract to be tested based on market information.

[0101] In the embodiment of the present application, the request sending module 302 may specifically include the following submodules:

[0102] The contract traversal submodule is used to traverse all contracts to be tested and determine the target interface corresponding to each contract to be tested in the target trading system. Different contracts to be tested correspond to different target interfaces.

[0103] The target sending submodule is used to send an order request to the corresponding target interface in the target trading system for each contract to be tested.

[0104] In the embodiment of the present application, the abnormal contract testing device 3 may further include the following modules:

[0105] The status receiving module is used to receive the transaction status of the corresponding contract to be tested returned by each target interface in the target trading system.

[0106] In the embodiment of the present application, the abnormal contract testing device 3 may further include the following modules:

[0107] The instruction sending module is used to send a generation instruction and a target file path to the target trading system. The generation instruction is used to instruct the target trading system to generate a test report for the abnormal contract, and the target file path is used to store the test report.

[0108] In the embodiment of the present application, the abnormal contract testing device 3 may further include the following modules:

[0109] A parameter value acquisition module is used to obtain the target parameter value of the abnormal contract. The target parameter value is used to indicate the level of detail of the contract information recorded in the abnormal contract.

[0110] The information storage module is used to store the contract information in the abnormal contract according to the target parameter value.

[0111] The testing device for abnormal contracts provided in the embodiment of the present application can be applied in the aforementioned method embodiment. For details, please refer to the description of the aforementioned method embodiment, which will not be repeated here.

[0112] Figure 4 Schematic diagram of the structure of the terminal device provided in the fourth embodiment of the present application. Figure 4 As shown, the terminal device 400 of this embodiment includes: at least one processor 410 ( Figure 4 Only one is shown in the figure) a processor, a memory 420, and a computer program 421 stored in the memory 420 and executable on the at least one processor 410, and when the processor 410 executes the computer program 421, the steps in any of the above-mentioned abnormal contract testing method embodiments are implemented.

[0113] The terminal device 400 may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The terminal device may include, but is not limited to, a processor 410 and a memory 420. Those skilled in the art will appreciate that Figure 4 It is only an example of the terminal device 400 and does not constitute a limitation on the terminal device 400. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components, for example, it may also include input and output devices, network access devices, etc.

[0114] The processor 410 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0115] In some embodiments, the memory 420 may be an internal storage unit of the terminal device 400, such as a hard disk or memory of the terminal device 400. In other embodiments, the memory 420 may also be an external storage device of the terminal device 400, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the terminal device 400. Further, the memory 420 may also include both an internal storage unit of the terminal device 400 and an external storage device. The memory 420 is used to store an operating system, an application program, a boot loader (BootLoader), data, and other programs, such as the program code of the computer program, etc. The memory 420 may also be used to temporarily store data that has been output or is to be output.

[0116] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0117] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0118] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0119] In the embodiments provided in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0121] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0122] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0123] The present application implements all or part of the processes in the above-mentioned embodiment method, and may also be completed through a computer program product. When the computer program product runs on a terminal device, the terminal device can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0124] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application is described in detail with reference to the above-mentioned embodiments, a person skilled in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for testing abnormal contracts, characterized in that: The test method includes: Obtaining the contract preset transaction price corresponding to the contract to be tested in the target trading system, wherein the contract to be tested refers to the contract generated for both parties after the order is successfully matched; Sending an order request to the target trading system according to the preset transaction price of the contract, wherein the order request is used to instruct the target trading system to simulate the transaction process of the contract to be tested based on the preset transaction price of the contract, and return the transaction status of the contract to be tested generated by the transaction process, wherein the order request is also used to instruct the target trading system to compare the actual transaction price corresponding to the contract to be tested with the preset transaction price of the contract, if the actual transaction price is the same as the preset transaction price of the contract, then the transaction status of the contract to be tested is concluded to be completed, and if the actual transaction price is different from the preset transaction price of the contract, then the transaction status of the contract to be tested is concluded to be undealt; If the received transaction status of the contract to be tested is untransacted, it is determined that the contract to be tested is an abnormal contract.

2. The testing method according to claim 1, characterized in that: The test method also includes: If the transaction status of the contract to be tested is not received within the preset time period, the contract to be tested is determined to be an abnormal contract.

3. The testing method according to claim 1, characterized in that: The step of obtaining the preset transaction price of the contract corresponding to the contract to be tested in the target trading system includes: Obtaining market information corresponding to the contract to be tested, wherein the market information at least includes a mapping relationship between the contract to be tested and a preset transaction price of the contract; The contract preset transaction price corresponding to the contract to be tested is determined according to the market information.

4. The testing method according to claim 1, characterized in that: When the number of the contracts to be tested is at least two, sending an order request to the target trading system according to the preset transaction price of the contract includes: Traversing all the contracts to be tested, determining the target interface corresponding to each of the contracts to be tested in the target trading system, where different contracts to be tested correspond to different target interfaces; For each of the contracts to be tested, an order request is sent to the corresponding target interface in the target trading system.

5. The testing method according to claim 4, characterized in that: The test method also includes: Receive the transaction status of the corresponding contract to be tested returned by each target interface in the target trading system.

6. The testing method according to any one of claims 1 to 5, characterized in that: After determining that the contract to be tested is an abnormal contract, the method further includes: A generation instruction and a target file path are sent to the target trading system, wherein the generation instruction is used to instruct the target trading system to generate a test report for the abnormal contract, and the target file path is used to store the test report.

7. The testing method according to any one of claims 1 to 5, characterized in that: After determining that the contract to be tested is an abnormal contract, the method further includes: Obtaining a target parameter value of the abnormal contract, where the target parameter value is used to indicate a level of detail of recording contract information in the abnormal contract; According to the target parameter value, the contract information in the abnormal contract is stored.

8. A testing device for abnormal contracts, characterized in that: The testing device comprises: An acquisition module is used to obtain a preset transaction price of a contract corresponding to a contract to be tested in a target trading system, wherein the contract to be tested refers to a contract generated for both parties to a transaction after an order is successfully matched; A request sending module, used for sending an order request to the target trading system according to the preset transaction price of the contract, wherein the order request is used to instruct the target trading system to simulate the transaction process of the contract to be tested based on the preset transaction price of the contract, and return the transaction status of the contract to be tested generated by the transaction process, wherein the order request is also used to instruct the target trading system to compare the actual transaction price corresponding to the contract to be tested with the preset transaction price of the contract, if the actual transaction price is the same as the preset transaction price of the contract, then the transaction status of the contract to be tested is concluded to be completed, if the actual transaction price is different from the preset transaction price of the contract, then the transaction status of the contract to be tested is concluded to be undealt; The first abnormality determination module is used to determine that the contract to be tested is an abnormal contract if the transaction status of the contract to be tested received is not completed.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium storing 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 7 is implemented.

Images