Visual futures trading software automatic testing method

Abstract

The invention discloses a visual futures transaction software automatic test method, which comprises the following specific steps: design of execution cases, maintenance of case machines, combination of test cases CASE and setting of case test plans, and the plan setting comprises a catalog where test codes are located, CASE execution times, test machines and cases executed by corresponding machines, standby machines and case execution. By means of the method, the test efficiency can be improved, meanwhile, the error probability is reduced, machine resources are fully utilized, through the timed tasks, the use cases are automatically executed at night, the resource utilization rate is fully improved, the test time consumption is reduced, the use case execution results are fully automatically collected, and the use case execution results are stored; the software designed through the method is easy to deploy and migrate, can be used immediately after being decompressed, is adaptive to various systems, can be executed only by opening a browser, and does not need to install any client side.

Description

Technical Field

[0001] The present invention relates to the field of financial transactions, and is specifically an automatic testing method for visual futures trading software. Background Art

[0002] Most of the currently available software automatic testing tools can only support single-machine testing, and many testing tools must rely on specific IDE development tools and development languages ​​to run. The method of the present invention naturally supports multi-machine joint testing, without development language and IDE tool dependence, and no additional system dependence. The main difficulty in realizing multi-machine joint testing is the concurrent control of the multi-machine environment. In the past, it was mainly due to the lack of a unified centralized mechanism for coordinating the operation of each machine. The method of the present invention focuses on solving the above problems. The futures trading software involved in this method is a software designed by the methods described in the two patents "A reliable multicast automatic ID allocation method and system (CN201911287501.1)" and "A reliable multicast software implementation method (CN202010694628.1)". Unless otherwise specified, the "futures software" appearing in the subsequent content refers to this software. Summary of the invention

[0003] The present invention aims at the problem that most software automatic testing tools can only support single-machine testing and many testing tools must rely on specific IDE development tools and development languages ​​to run, and provides a visual futures trading software automatic testing method.

[0004] In order to solve the above problems, the present invention provides a visual futures trading software automatic testing method, which specifically includes the following steps:

[0005] S1: Design and execute use cases. According to the business requirements of futures software account opening, trading, settlement, risk management, and fund management, design the use cases in the shell script format under the Linux operating system. The use cases are customizable, including calling the process in the futures software, passing parameters, setting the configuration required for operation, and operating process control. During the execution of the use cases, the keywords of execution success and failure are clearly output, and the keyword content can be customized;

[0006] S2: The use case machine maintenance, the use case execution needs to rely on the Linux server, the server can be a physical machine, a virtual machine, a container, the available server resources need to be entered into the automatic test system, the entry information includes IP address, user name and password, port number information, user name and password of the code management software, the code management software supports SVN and Git;

[0007] S3: Test case CASE combination. Business scenarios require multiple test cases to be jointly executed. This method supports multiple execution cases to be superimposed in sequence to form new test cases. Each machine can execute any combination of original CASE cases and composite cases. CASE1, CASE2, and CASE3 represent three different business cases. The two cases CASE1 and CASE2 are combined to generate the fourth business scenario. The execution result of the combined case is obtained by outputting the keyword of the last case in the combined case.

[0008] S4: Use case test plan setting, the interface input field enters the directory where the test code is located, the number of CASE executions, the test machine, and the information of the backup machine. The backup machine refers to the test scenario that requires other machines to assist. After the entry is completed, the automatic test system will summarize and save the entered information into a specific test plan and name it with the name entered by the user. The test machine and the backup machine can be selected multiple times;

[0009] Execution use case: executing the specific Shell script program under the Linux operating system;

[0010] Directory where the test code is located: the directory where the source code of the futures software program being tested is located;

[0011] CASE execution times: The specific execution times of the CASE are the numerical information entered in the page input field in the step S4, and are executed independently without relying on the last execution result;

[0012] Test machines and use cases executed by corresponding machines: machines that execute the use cases. There may be multiple machines, and each machine is set to execute a specific use case.

[0013] Backup machine: The use case scenario is a primary-backup scenario. A machine is provided as a backup point for testing. When machine 1 executes CASE1, CASE1 is the primary-backup scenario. A backup machine 2 is provided for machine 1. The CASE1 use case will execute the primary-backup scenario use case in machine 1 and machine 2.

[0014] The test machine without the backup machine is called a single machine type, one backup machine is called a dual machine type, two backup machines are called a triple machine type, and a maximum of three machine types are supported, but there is no limit on the number of the test machines and the backup machines;

[0015] S5: Use case execution. After setting the test case execution plan in step S4, you can choose to execute immediately or add timing. If you choose to execute immediately, the use case will start to execute immediately on the current interface and display the execution result in real time. If you choose to add timing, select the type of the plan, single machine, dual machine, or three machines. The test plan will be added to the scheduled task, and a queue will be generated in the memory. The queue will store the use cases that need to be executed in the task and wait for the scheduled task system to call. The execution result will be written to the database.

[0016] S6: Check the execution result of the use case, obtain the relevant information in the database accessed in step S5, and provide a viewing interface;

[0017] S7: Scheduled task execution. The scheduled task needs to be set at a scheduled time. Enter the scheduled task execution time and the scheduled task name respectively, click the Add button to set the scheduled task. After the scheduled task is executed, check the execution result through the S6 step. During the execution of the scheduled task, check the remaining cases in the queue in the S5 step once per second. If there are redundant machine resources available for the remaining cases, regenerate a temporary scheduled task, and send the unexecuted cases to other idle machines for execution through SSH requests;

[0018] S8: Reliability test, perform reliable regression test on the use case. When setting the test plan, set the number of execution times of the use case. The use case can be executed in a loop within the set number of times until the number is exhausted or a problem is found, and automatically capture the log when the problem occurs, as well as the memory image generated by the Linux operating system when the C++ program crashes and the program debugging core file.

[0019] In a preferred embodiment, the SVN and Git in step S2 collaborate with the software team developers to archive the complete work history.

[0020] In a preferred manner, the use case combination in the step S3 does not limit the use case combination scenario, and the scenario is determined by the business scenario itself.

[0021] In a preferred manner, the execution result in the step S5 includes which use case is executed, which server is used, and the detailed information of the execution process in the step S1 output in real time by the use case, as well as the result of success or failure of the execution of the use case.

[0022] The beneficial effects of the present invention are: the relevant business scenarios of futures software in a multi-machine software environment can be tested, such as cluster master selection, cold standby recovery, load balancing, etc. Compared with the previous text editing test case execution, the present method can greatly improve the test efficiency, reduce the error probability, make full use of machine resources, and automatically find idle machines for case execution allocation; at the same time, the scheduled task can be used to automatically execute the case at night, fully improve resource utilization, reduce test time, and collect the results of the full-automatic case execution, and save the case execution results for easy viewing in the future. The present method supports regression testing of problems that are not easy to find. The case can be executed arbitrarily many times until the number is exhausted or the problem is found. The software designed by the present method is simple to deploy and migrate, without installing any dependencies, and can be used after decompression, and is compatible with multiple systems such as Windows, Linux, and Mac. At the same time, it is simple to use. The user only needs to open the browser to execute it without installing any client. The innovative support for distributed multi-machine software system business scenario testing meets the testing requirements under multi-machine scenarios. According to the usage of machine resources, the machines are uniformly scheduled and resources are allocated, and idle resources are automatically allocated to maximize the use of machine resources. The innovative cyclic testing mode is used until abnormal problems are found, which is conducive to solving occasional futures software defect testing problems. The test plan is set through a graphical interface and is saved in real time, which can be viewed and executed at any time. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a business process decomposition diagram. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0025] Embodiment 1:

[0026] See also Figure 1 , the present invention provides a technical solution:

[0027] Step 1: Design an execution use case. According to the business requirements of "futures software", it is necessary to design a use case in the shell script format under the Linux operating system in advance. The use case execution content is customized, but the keywords for successful and failed execution must be clearly output during the use case execution process. The keyword content can be customized. The method of the present invention needs to use the keyword to judge the use case execution result in the later stage.

[0028] Step 2: Use case machine maintenance (subsequent steps need to be performed through the browser). Use case execution requires a Linux server, which can be a physical machine, a virtual machine, or a container. The available server resources need to be entered into the system, including the IP address, username and password, port number information, and the username and password of the code management software. The code management software supports SVN and Git.

[0029] Step 3: Test case CASE combination. Some business scenarios require different test cases to be executed jointly, so this method supports combining multiple test cases into a new "use case". Each machine can execute any combination of original CASE cases and "composite use cases". For example, "CASE1", "CASE2", and "CASE3" represent three different business use cases, each of which represents a business scenario. The two use cases "CASE1 CASE2" can be combined to generate a fourth business scenario. This method does not limit the use case combination scenario. Whether the use case can be combined is entirely determined by the business scenario itself. This release determines the execution result of the combined use case by the output keyword of the last use case in the combined use case.

[0030] Step 4: Use case test plan setting. This method supports entering the directory where the test code is located, the number of CASE executions, the test machine and the use cases executed by the corresponding machine, the backup machine and other factors, and formulating a test plan based on these factors, where both the test machine and the backup machine can be selected multiple times.

[0031] The directory where the test code is located: refers to the directory where the source code of the futures software program to be tested is located.

[0032] Number of CASE executions: refers to the specific number of times the CASE is executed. Each execution is independent and does not depend on the result of the previous execution.

[0033] Test machines and use cases executed by the corresponding machines: refers to the machines that specifically execute the use cases. There can be multiple machines, and which use cases to execute are set for each machine.

[0034] Backup machine: A backup machine refers to a scenario where some use cases are active and standby. In this case, a machine needs to be provided as a backup point to facilitate testing. For example, machine 1 executes CASE1, where CASE1 is an active and standby scenario. In this case, backup machine 2 is provided for machine 1. In this way, the CASE1 use case will execute the active and standby scenario use case in machine 1 and machine 2, and will not run to other machines.

[0035] If the test machine has no backup machine, it is called a single-machine type; if there is one backup machine, it is called a dual-machine type; if there are two backup machines, it is called a triple-machine type. This method is designed to support up to three-machine types, but there is no limit on the number of test machines and backup machines.

[0036] Step 5: Use case execution. After setting the test case execution plan in "Step 4", you can choose to execute immediately or add a timer. If you choose to execute immediately, the use case will start executing immediately on the current interface and display the execution results in real time. The execution results include the number of use cases currently executed, which server is used, and the real-time output of the use case and the execution results of the use case. If you choose to add a timer, you need to select the type of the plan (single machine, dual machine, three machines), and then the test plan will be added to the scheduled task and wait for the scheduled task system to call. During the system execution process, information such as the execution results, execution time, execution personnel, and the output content of the execution use case will be written into the database.

[0037] Step 6: View the test case execution results. Get relevant information from the database and provide a viewing interface to view the past test history of yourself and others.

[0038] Step 7: Scheduled task execution. Scheduled tasks require the setting of a scheduled time. This method can set multiple scheduled tasks through the interface. Each scheduled task executes a test plan, and scheduled tasks in different time periods have no impact on each other. After the scheduled task is executed, you can view the execution results through "Step 6". The results include execution time, execution status, number of machines, number of cases, number of passed tests, number of failed tests, and the test execution log can be downloaded. If it is found during the execution of a scheduled task that there are many subsequent tasks and there are still extra machine resources available, other idle machines will be "borrowed" to execute the remaining test cases in the test plan.

[0039] Step 8: Reliability test. This tool supports regression testing of use cases. When setting the test plan, you can set the number of use case executions. The use case can be executed repeatedly within the set number of times until the number is exhausted or a problem is found. It also automatically captures the log when the problem occurs and the core file when the C++ program crashes.

[0040] Embodiment 2:

[0041] A visual futures trading software automatic testing method, specifically the following steps:

[0042] S1: Design and execute use cases. According to the business requirements of futures software account opening, trading, settlement, risk management, and fund management, design the use cases in the shell script format under the Linux operating system. The use cases are customizable, including calling the process in the futures software, passing parameters, setting the configuration required for operation, and operating process control. During the execution of the use cases, the keywords of execution success and failure are clearly output, and the keyword content can be customized;

[0043] S2: The use case machine maintenance, the use case execution needs to rely on the Linux server, the server can be a physical machine, a virtual machine, a container, the available server resources need to be entered into the automatic test system, the entry information includes IP address, user name and password, port number information, user name and password of the code management software, the code management software supports SVN and Git;

[0044] S3: Test case CASE combination. Business scenarios require multiple test cases to be jointly executed. This method supports multiple execution cases to be superimposed in sequence to form new test cases. Each machine can execute any combination of original CASE cases and composite cases. CASE1, CASE2, and CASE3 represent three different business cases. The two cases CASE1 and CASE2 are combined to generate the fourth business scenario. The execution result of the combined case is obtained by outputting the keyword of the last case in the combined case.

[0045] S4: Use case test plan setting, the interface input field enters the directory where the test code is located, the number of CASE executions, the test machine, and the information of the backup machine. The backup machine refers to the test scenario that requires other machines to assist. After the entry is completed, the automatic test system will summarize and save the entered information into a specific test plan and name it with the name entered by the user. The test machine and the backup machine can be selected multiple times;

[0046] Execution use case: executing the specific Shell script program under the Linux operating system;

[0047] Directory where the test code is located: the directory where the source code of the futures software program being tested is located;

[0048] CASE execution times: The specific execution times of the CASE are the numerical information entered in the page input field in the step S4, and are executed independently without relying on the last execution result;

[0049] Test machines and use cases executed by corresponding machines: machines that execute the use cases. There may be multiple machines, and each machine is set to execute a specific use case.

[0050] Backup machine: The use case scenario is a primary-backup scenario. A machine is provided as a backup point for testing. When machine 1 executes CASE1, CASE1 is the primary-backup scenario. A backup machine 2 is provided for machine 1. The CASE1 use case will execute the primary-backup scenario use case in machine 1 and machine 2.

[0051] The test machine without the backup machine is called a single machine type, one backup machine is called a dual machine type, two backup machines are called a triple machine type, and a maximum of three machine types are supported, but there is no limit on the number of the test machines and the backup machines;

[0052] S5: Use case execution. After setting the test case execution plan in step S4, you can choose to execute immediately or add timing. If you choose to execute immediately, the use case will start to execute immediately on the current interface and display the execution result in real time. If you choose to add timing, select the type of the plan, single machine, dual machine, or three machines. The test plan will be added to the scheduled task, and a queue will be generated in the memory. The queue will store the use cases that need to be executed in the task and wait for the scheduled task system to call. The execution result will be written to the database.

[0053] S6: Check the execution result of the use case, obtain the relevant information in the database accessed in step S5, and provide a viewing interface;

[0054] S7: Scheduled task execution. The scheduled task needs to be set at a scheduled time. Enter the scheduled task execution time and the scheduled task name respectively, click the Add button to set the scheduled task. After the scheduled task is executed, check the execution result through the S6 step. During the execution of the scheduled task, check the remaining cases in the queue in the S5 step once per second. If there are redundant machine resources available for the remaining cases, regenerate a temporary scheduled task, and send the unexecuted cases to other idle machines for execution through SSH requests;

[0055] S8: Reliability test, perform reliable regression test on the use case. When setting the test plan, set the number of execution times of the use case. The use case can be executed in a loop within the set number of times until the number is exhausted or a problem is found, and automatically capture the log when the problem occurs, as well as the memory image generated by the Linux operating system when the C++ program crashes and the program debugging core file.

[0056] The SVN and Git described in step S2 collaborate with the software team developers to archive the complete work history.

[0057] The use case combination in the step S3 does not limit the use case combination scenario, which is determined by the business scenario itself.

[0058] The execution result in step S5 includes which use case is executed, which server is used, and the detailed information of the execution process in step S1 output in real time by the use case, as well as the result of success or failure of the execution of the use case.

[0059] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A visual futures trading software automatic testing method, characterized in that: The specific steps are as follows: S1: Design and execute use cases. According to the business requirements of futures software account opening, trading, settlement, risk management, and fund management, design the use cases in the shell script format under the Linux operating system. The use cases are customizable, including calling the process in the futures software, passing parameters, setting the configuration required for operation, and operating process control. During the execution of the use cases, the keywords of execution success and failure are clearly output, and the keyword content can be customized; S2: The use case machine maintenance, the use case execution needs to rely on the Linux server, the server can be a physical machine, a virtual machine, a container, the available server resources need to be entered into the automatic test system, the entry information includes IP address, user name and password, port number information, user name and password of the code management software, the code management software supports SVN and Git; S3: Test case CASE combination. Business scenarios require multiple test cases to be jointly executed. This method supports multiple execution cases to be superimposed in sequence to form new test cases. Each machine can execute any combination of original CASE cases and composite cases. CASE1, CASE2, and CASE3 represent three different business cases. The two cases CASE1 and CASE2 are combined to generate the fourth business scenario. The execution result of the combined case is obtained by outputting the keyword of the last case in the combined case. S4: Use case test plan setting, the interface input field enters the directory where the test code is located, the number of CASE executions, the test machine, and the information of the backup machine. The backup machine refers to the test scenario that requires other machines to assist. After the entry is completed, the automatic test system will summarize and save the entered information into a specific test plan and name it with the name entered by the user. The test machine and the backup machine can be selected multiple times; Execution use case: executing the specific Shell script program under the Linux operating system; Directory where the test code is located: the directory where the source code of the futures software program being tested is located; CASE execution times: The specific execution times of the CASE are the numerical information entered in the page input field in step S4, and are executed independently without relying on the last execution result; Test machines and use cases executed by corresponding machines: machines that execute the use cases. There may be multiple machines, and each machine is set to execute a specific use case. Backup machine: The use case scenario is a primary-backup scenario. A machine is provided as a backup point for testing. When machine 1 executes CASE1, CASE1 is the primary-backup scenario. A backup machine 2 is provided for machine 1. The CASE1 use case will execute the primary-backup scenario use case in machine 1 and machine 2. The test machine without the backup machine is called a single machine type, one backup machine is called a dual machine type, two backup machines are called a triple machine type, and a maximum of three machine types are supported, but there is no limit on the number of the test machines and the backup machines; S5: Use case execution. After setting the test case execution plan in step S4, you can choose to execute immediately or add timing. If you choose to execute immediately, the use case will start to execute immediately on the current interface and display the execution result in real time. If you choose to add timing, select the type of the plan, single machine, dual machine, or three machines. The test plan will be added to the scheduled task, and a queue will be generated in the memory. The queue will store the use cases that need to be executed in the task and wait for the scheduled task system to call. The execution result will be written to the database. S6: View the execution result of the use case, obtain the relevant information in the database accessed in step S5, and provide a viewing interface; S7: Scheduled task execution. The scheduled task needs to be set at a scheduled time. Enter the scheduled task execution time and the scheduled task name respectively, click the Add button to set the scheduled task. After the scheduled task is executed, check the execution result through the S6 step. During the execution of the scheduled task, check the remaining cases in the queue in the S5 step once per second. If there are redundant machine resources available for the remaining cases, regenerate a temporary scheduled task, and send the unexecuted cases to other idle machines for execution through SSH requests; S8: Reliability test, perform reliable regression test on the use case. When setting the test plan, set the number of execution times of the use case. The use case can be executed in a loop within the set number of times until the number is exhausted or a problem is found, and automatically capture the log when the problem occurs, as well as the memory image generated by the Linux operating system when the C++ program crashes and the program debugging core file.

2. The method for automatically testing visual futures trading software according to claim 1 is characterized in that: The SVN and Git described in step S2 collaborate with the software team developers to archive the complete work history.

3. The method for automatically testing visual futures trading software according to claim 1 is characterized in that: The use case combination in the step S3 does not limit the use case combination scenario, which is determined by the business scenario itself.

4. The method for automatically testing visual futures trading software according to claim 1 is characterized in that: The execution result in step S5 includes which use case is executed, which server is used, and the detailed information of the execution process in step S1 output in real time by the use case, as well as the result of success or failure of the execution of the use case.

Images