Project case test method and device, computer device and storage medium

Abstract

The application relates to a project case testing method and device, computer equipment and a storage medium. The method comprises the following steps: obtaining a to-be-tested project case, dividing each test task according to the task parameters of each test task to obtain a divided test task, calling a daily terminal file corresponding to the divided test task, and testing the to-be-tested project case. The method can improve the testing efficiency of the to-be-tested project case in the financial industry.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to a project case testing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the rapid development of information technology, the financial industry has made significant progress in its informatization. Typically, after the close of business each day, the financial industry needs to reconcile accounts and cash, generating end-of-day documents that record the daily flow of accounts and cash.

[0003] Typically, testing projects in the financial industry requires accessing corresponding end-of-day files. However, during this testing process, the financial project under test may need to access the end-of-day files multiple times, resulting in low testing efficiency in existing technologies for testing projects in the financial industry. Summary of the Invention

[0004] Therefore, it is necessary to provide a project case testing method, apparatus, computer equipment, and storage medium that can improve testing efficiency in response to the above-mentioned technical problems.

[0005] A project case testing method, the method comprising:

[0006] Obtain test cases for projects to be tested; each test case includes at least two test tasks.

[0007] The test tasks are divided according to their task parameters to obtain the divided test tasks.

[0008] The end-of-day file corresponding to the divided test task is invoked to test the test case of the project to be tested.

[0009] In one embodiment, the step of dividing each test task according to the task parameters of each test task to obtain the divided test tasks includes:

[0010] Based on the task identifier of each test task, sort the test tasks to obtain the sorted test tasks;

[0011] Based on the task attribute information of each test task, the sorted test tasks are divided into a first task and a second task; wherein the framework type to which the first task belongs is different from the framework type to which the second task belongs; the execution priority of the first task is higher than the execution priority of the second task.

[0012] In one embodiment, the task identifier of each test task is used to characterize the execution order of each test task; the task attribute information of each test task includes the execution position of the subtasks in each test task.

[0013] In one embodiment, the step of calling the end-of-day file corresponding to the divided test task is...

[0014] The test case of the project to be tested is tested, including:

[0015] Call the end-of-day file corresponding to the first task and determine whether the execution time of the first task is consistent with the execution time of the end-of-day file corresponding to the first task;

[0016] If so, execute the end-of-day file corresponding to the first task, and execute the end-of-day file corresponding to the second task after the end-of-day file corresponding to the first task has been executed.

[0017] In one embodiment, the method further includes:

[0018] If the execution time of the first task is inconsistent with the execution time of the end-of-day file corresponding to the first task, then the end-of-day file corresponding to the second task is invoked and executed.

[0019] In one embodiment, the method further includes: collecting first parameter information during the execution of the end-of-day file corresponding to the first task and second parameter information during the execution of the end-of-day file corresponding to the second task; the first parameter information includes the execution status information of the first task; and the second parameter information includes the execution status information of the second task.

[0020] In one embodiment, before dividing the test tasks according to the task parameters of each test task to obtain the divided test tasks, the method further includes:

[0021] Determine whether the test case is in an idle state;

[0022] If so, the test tasks are divided according to their task parameters to obtain the divided test tasks.

[0023] A project case testing device, the device comprising:

[0024] The first acquisition module is used to acquire test cases; the test cases include at least two test tasks.

[0025] The second acquisition module is used to divide each test task according to the task parameters of each test task to obtain the divided test tasks.

[0026] The testing module is used to call the end-of-day files corresponding to the divided test tasks and test the test cases of the project to be tested.

[0027] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps:

[0028] Obtain test cases for projects to be tested; each test case includes at least two test tasks.

[0029] The test tasks are divided according to their task parameters to obtain the divided test tasks.

[0030] The end-of-day file corresponding to the divided test task is invoked to test the test case of the project to be tested.

[0031] A computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0032] Obtain test cases for projects to be tested; each test case includes at least two test tasks.

[0033] The test tasks are divided according to their task parameters to obtain the divided test tasks.

[0034] The end-of-day file corresponding to the divided test task is invoked to test the test case of the project to be tested.

[0035] The aforementioned project case testing method, apparatus, computer equipment, and storage medium acquire the project cases to be tested. Each project case includes at least two test tasks, allowing the test tasks to be divided according to their task parameters. This classifies test tasks with the same type of task parameters into the same type of test tasks. The day-end files corresponding to the divided test tasks can then be called to test the project cases. Because the server classifies test tasks with the same type of task parameters into the same type of test tasks, the day-end files corresponding to the divided test tasks are the same type of test tasks, thus saving the time required to call the day-end files and further reducing the testing time for the project cases, thereby improving the testing efficiency. Attached Figure Description

[0036] Figure 1 This is a diagram illustrating the application environment of the test method for a project case in one embodiment.

[0037] Figure 2This is a flowchart illustrating the testing method for a project case in one embodiment;

[0038] Figure 3 This is a flowchart illustrating the project case testing method in another embodiment;

[0039] Figure 4 This is a flowchart illustrating the test method for a project case in yet another embodiment;

[0040] Figure 5 This is a flowchart illustrating the test method for a project case in yet another embodiment;

[0041] Figure 6 This is a flowchart illustrating the test method for a project case in yet another embodiment;

[0042] Figure 7 This is a flowchart illustrating the test method for a project case in yet another embodiment;

[0043] Figure 8 This is a structural block diagram of the test device for a project case in one embodiment;

[0044] Figure 9 This is a structural block diagram of the test device for a project case in one embodiment;

[0045] Figure 10 This is a structural block diagram of the test device for a project case in one embodiment;

[0046] Figure 11 This is a structural block diagram of the test device for a project case in one embodiment;

[0047] Figure 12 This is a structural block diagram of the test device for a project case in one embodiment;

[0048] Figure 13 This is a structural block diagram of the test device for a project case in one embodiment. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0050] The project case testing methods provided in this application can be applied to, for example... Figure 1 The server shown. The internal structure of this server can be seen as follows: Figure 1As shown, the server includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs in the non-volatile storage media to run. The server's database stores project case test data. The server's network interface is used to communicate with external terminals via a network connection. The server first obtains the project cases to be tested, divides each test task according to its task parameters, and calls the corresponding end-of-day files for each divided test task to test the project cases. The server can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0051] In one embodiment, such as Figure 2 As shown, a project case testing method is provided, which is applied to... Figure 1 Taking the server in the example, the following steps are included:

[0052] S201, Obtain test cases for projects to be tested; the test cases for projects to be tested include at least two test tasks.

[0053] The test cases are used to test the software products developed and designed for the financial system. Each test case must include at least two test tasks. For example, a test case could be the C1 test case, which refers to a case related to enterprise cash flow management, settlement management, asset and liability management, investment and financial management, and risk management. Each test case must include at least two test tasks; for instance, test case A could include three test tasks: A1, A2, and A3.

[0054] In this embodiment, the test cases usually have pre-set case tags. The server can obtain the test cases according to the pre-set case tags, or the server can directly obtain the test cases from the memory of the financial system at preset time intervals.

[0055] Furthermore, it should be noted that different test tasks included in the test project case can correspond to different data format messages. Taking the above test project case A, which includes three test tasks A1, A2, and A3, as an example, the message format corresponding to test task A1 can be a JSON (JavaScript Object Notation, JS) message, and the message format corresponding to test task A2 can be an XML (Extensible Markup Language, XML) message. Typically, in existing technologies, different conversion interfaces are needed to convert messages of different data formats into messages of a unified standard data format. For example, there is one input interface for JSON format messages and another for XML format messages. If JSON and XML format messages are input into the Retrofit2 test framework at the same time, two different interfaces in the test framework are needed to convert the JSON and XML format messages respectively, which results in low conversion efficiency. This embodiment modifies the Retrofit2 test framework by performing secondary development, using the same conversion interface with different code configurations to parse messages of different data formats and convert them into messages of a unified standard data format. For example, test task A1 may be a message in JSON (JavaScript Object Notation, JS) format, test task A2 may be a message in XML (Extensible Markup Language, XML) format, and test task A3 may also be a message in XML format. In this embodiment, when three test tasks with different message formats are obtained, the server can convert the three test tasks into JSON format or convert them into XML format. That is, in this embodiment, JSON format messages and XML format messages can be input and converted simultaneously through a single interface, converting messages of different formats into the same message format.

[0056] S202, divide each test task according to the task parameters of each test task to obtain the divided test tasks.

[0057] The task parameters for each test task serve as the basis for dividing the test tasks. Optionally, the task parameters for each test task can be the date of the test task; or, each test task generally corresponds to a daily end-of-day file, which can be used to test each test task. Therefore, the task parameters for each test task can also be the start time of the daily end-of-day file, etc.

[0058] In this embodiment, optionally, the server can classify the test tasks according to their task parameters using Naive Bayes classification or Support Vector Machine classification, resulting in the classified test tasks. For example, when the task parameter of each test task is the date, the test tasks can be classified using Naive Bayes classification to group test tasks whose dates fall within the same time range into the same category. For instance, test tasks with dates from January 1st to January 30th can be classified as the first category, and test tasks with dates from February 1st to February 30th can be classified as the second category.

[0059] S203 calls the end-of-day file corresponding to the divided test tasks and performs tests on the test cases.

[0060] The end-of-day document is usually triggered when the finance company closes for the day. It is a document obtained by clearing up the finance company's daytime business. During the generation of the end-of-day document, the company system will not perform other business. The calculation process of the end-of-day document includes calculating interest, accruing interest, automatic repayment, settling contracts, extending or transferring contracts to overdue, checking the finance company's accounting records, and updating account balances.

[0061] In this embodiment, the divided test tasks are obtained through step S202. Optionally, the end-of-day files corresponding to each test task can be identified in advance. It is understood that the identifiers of the end-of-day files corresponding to different test tasks are different. Therefore, the server can call the end-of-day files corresponding to the divided test tasks through the identifiers of the end-of-day files corresponding to each test task. Alternatively, there is a one-to-one correspondence between the test tasks and their corresponding end-of-day files. The server can also call the end-of-day files corresponding to the test tasks through the correspondence between the test tasks and the end-of-day files, and perform tests on the test cases based on the obtained end-of-day files.

[0062] In the above-described project case testing method, by acquiring the project cases to be tested, each project case includes at least two test tasks. The test tasks can then be divided according to their parameters, grouping test tasks with the same type of parameters into the same category. The corresponding end-of-day files for these divided test tasks can then be called to test the project cases. Since the server groups test tasks with the same type of parameters into the same category, the called end-of-day files for these divided test tasks are for the same category of test tasks, saving time on file retrieval and further reducing testing time for the project cases, thus improving testing efficiency.

[0063] Optionally, a specific implementation of S202 above is provided, such as... Figure 3 As shown, the method includes:

[0064] S301, sort the test tasks according to their task identifiers to obtain the sorted test tasks.

[0065] Optionally, in this embodiment, the task identifier of each test task is used to represent the execution order of each test task. The server can sort the test tasks according to their execution order. Optionally, the task identifier of each test task can also represent the importance of each test task. For example, the most important test task can be identified by the identifier 1, and the next most important test task can be identified by the identifier 2. The test tasks are then identified sequentially in this way, and can be arranged in ascending order of their identifiers or in descending order of their identifiers to obtain the sorted test tasks. Optionally, the task identifier of each test task can also represent the dependency of each test task. For example, test task A can only be tested after test task B has been completed, while test task C can be completed independently. In this case, the independent test task C can be placed first, and the dependent test task can be placed last, resulting in the sorted test tasks as: test task C, test task B, test task A. Alternatively, the dependent test task can be placed first, and the independent test task can be placed last, resulting in the sorted test tasks as: test task B, test task A, test task C. This implementation does not limit the sorting method for each test task, as long as the sorting method can yield the sorted test tasks.

[0066] It should be noted that when sorting the test tasks, the sorting should be based on the number of end-of-day files that each test task needs to execute. When a test task is executing an end-of-day file, other test tasks must wait until the end-of-day file is completed before they can be executed. If the end-of-day files are at different times, it will affect the test results of other cases, causing the test results to be inconsistent with the expected results.

[0067] S302, based on the task attribute information of each test task, divide the sorted test tasks to obtain the first task and the second task.

[0068] It should be noted that the Testng testing framework includes a pre-execution section and a main body. Since the Testng testing framework main body requires the execution of one test case, the sorted test tasks need to be divided into first and second tasks based on their task attributes. The first task is the test task to be executed in the pre-execution section, and the second task is the test task to be executed in the Testng testing framework main body. For example, if the test cases are divided into three parts: first test case A1, second test case A2, and third test case A3, then third test case A3 is executed as the second task in the Testng testing framework main body, while first test case A1 and second test case A2 are executed as the first task in the pre-execution section.

[0069] In this embodiment, optionally, the task attributes of each test task are used to characterize the execution position of each test task. The server can divide the test tasks according to their execution positions. Optionally, the task attribute information of each test task can also be the importance of each test task. For example, important tasks in the sorted test tasks can be classified as first tasks, and tasks other than important tasks can be classified as second tasks. Alternatively, the task attribute information can also be the execution time of each test task. The server can classify tasks with earlier execution times in the sorted test tasks as first tasks, and tasks with later execution times in the sorted test tasks as second tasks.

[0070] In the above project case testing method, the test tasks are sorted according to their task identifiers to obtain sorted test tasks. Then, the sorted test tasks can be divided according to their task attribute information to obtain the first task and the second task. The process of dividing the test tasks first involves sorting the test tasks, and then dividing the sorted tasks into the first and second tasks according to their task attributes. Therefore, the test tasks can be flexibly divided according to different tasks, which can save subsequent testing time.

[0071] exist Figure 3 Based on the illustrated embodiment, in another embodiment, such as Figure 4 As shown, this document details the specific implementation method for calling the end-of-day files corresponding to the divided test tasks and testing the test cases, including:

[0072] S401, call the end-of-day file corresponding to the first task, and determine whether the execution time of the first task is consistent with the execution time of the end-of-day file corresponding to the first task. If yes, proceed to step S402; otherwise, proceed to step S403.

[0073] In this embodiment, the first task is the test task that needs to be executed in the preconditions, and the second task is the test task that needs to be executed in the main body of the Testng test framework. Therefore, the end-of-day file corresponding to the first task is called first, and it is determined whether the execution time of the first task and the corresponding end-of-day file are consistent. If they are consistent, the first task is executed; if they are inconsistent, the second task is executed.

[0074] S402, execute the end-of-day file corresponding to the first task, and execute the end-of-day file corresponding to the second task after the end-of-day file corresponding to the first task has been executed.

[0075] In this embodiment, when executing the end-of-day file corresponding to the first task, the first task condition corresponding to the first end-of-day file must first be executed. Therefore, if the execution time of the first task and the corresponding end-of-day file are consistent, the first task condition is executed. If the first task condition is met, the end-of-day file corresponding to the first task is executed. If the first task condition is not met, information such as the task status and failure reason during the execution of the first task is collected to warn subsequent tasks of the reason for the task's failure. After the end-of-day file corresponding to the first task is completed, the second task is executed.

[0076] S403, call and execute the end-of-day file corresponding to the second task.

[0077] In this embodiment, if the execution time of the first task is inconsistent with that of the corresponding end-of-day file, information such as the task status and failure reasons during the execution process is collected, and then the end-of-day file corresponding to the second task is invoked. Similarly, when executing the end-of-day file corresponding to the second task, the conditions for the second task corresponding to the second end-of-day file need to be executed first. Therefore, when executing the second task, it is necessary to determine whether the conditions for the second task have been met. If they have been met, the end-of-day file corresponding to the second task is executed. If they have not been met, information such as the task status and failure reasons during the execution process of the second task is collected to warn subsequent tasks of the reason for the task's failure.

[0078] In the above project case testing method, after dividing the test into the first task and the second task, the end-of-day file corresponding to the first task is first called, and it is determined whether the execution time of the first task is consistent with the execution time of the end-of-day file corresponding to the first task. If the execution time of the first task is consistent with the execution time of the corresponding end-of-day file, the end-of-day file of the first task is executed. After the end-of-day file corresponding to the first task is completed, the end-of-day file corresponding to the second task is executed. If the execution time of the first task is inconsistent with the execution time of the corresponding end-of-day file, the end-of-day file corresponding to the second task is executed directly. Dividing the test tasks into specific first and second tasks according to task attributes and executing the end-of-day files corresponding to the first and second tasks in sequence can save the time of the testing process and improve the accuracy of test task execution.

[0079] exist Figure 3 Based on the illustrated embodiment, in another embodiment, since the test task process is relatively complex and the test process may succeed or fail, it is necessary to collect parameter information during the test process. The above method further includes: collecting first parameter information during the execution of the end-of-day file corresponding to the first task and second parameter information during the execution of the end-of-day file corresponding to the second task; the first parameter information includes the execution status information of the first task; the second parameter information includes the execution status information of the second task.

[0080] In this embodiment, during the execution of the end-of-day file corresponding to the first task, the execution status of the first task, whether the first task was successfully executed, and the reason for the failure of the first task are used as first parameter information. The server collects the first parameter information corresponding to the first task during the execution of the first task. Further, if the collected information includes information about the failure of the first task, the failure information needs to be marked as failure information to warn subsequent tasks of the reason for the task's failure. When executing the end-of-day file corresponding to the second task, the execution status of the second task, whether the second task was successfully executed, and the reason for the failure of the second task need to be collected as second parameter information.

[0081] In the above project case test method, the first parameter information during the execution of the end-of-day file corresponding to the first task and the second parameter information during the execution of the end-of-day file corresponding to the second task are collected. By collecting the execution status information during the test, the entire test process can be clearly understood, providing a reference for subsequent test processes and improving the efficiency of the test process.

[0082] Before sorting the test tasks according to their task identifiers, it is necessary to determine whether the test cases are in an idle state. Only when they are in an idle state can the test tasks be sorted. In another embodiment, such as... Figure 5 As shown, the above method also includes:

[0083] S501, Determine whether the test case is in an idle state. If yes, proceed to step S502; otherwise, proceed to step S503.

[0084] In this embodiment, the test case may include end-of-day files. Therefore, during the invocation process, the same test case cannot be invoked by different instances at the same time; otherwise, unpredictable exceptions or failures may occur during runtime of the end-of-day files. Therefore, before dividing the test cases into test tasks, it is necessary to determine whether the current test case is being invoked.

[0085] S502, divide each test task according to the task parameters of each test task to obtain the divided test tasks.

[0086] S503, test exit.

[0087] In this embodiment, if the test case is in an idle state, that is, the test case is not being called at this time, then step S202 above can be executed; if the test case is not in an idle state, that is, the test case is being called at this time, then the test exits.

[0088] In the above project case testing method, it is determined whether the project case to be tested is in an idle state. If the project case to be tested is in an idle state, the test tasks are divided according to the task parameters of each test task to obtain the divided test tasks. By determining whether the project case to be tested is idle, the problem of simultaneous invocation of the project case to be tested and causing the end-of-day file chaos is avoided.

[0089] In one embodiment, such as Figure 6 As shown, to facilitate understanding by those skilled in the art, the project case testing method is described in detail below. This method may include:

[0090] S601, Obtain test case of the project to be tested;

[0091] S602, Determine whether the test case is in an idle state. If yes, proceed to step S603; otherwise, proceed to step S610.

[0092] S603, sort the test tasks according to their task identifiers to obtain the sorted test tasks;

[0093] S604. Based on the task attribute information of each test task, the sorted test tasks are divided to obtain the first task and the second task.

[0094] S605, call the end-of-day file corresponding to the first task, and determine whether the execution time of the first task is consistent with the execution time of the end-of-day file corresponding to the first task. If yes, proceed to step S606; otherwise, proceed to step S607.

[0095] S606, execute the end-of-day file corresponding to the first task, and execute the end-of-day file corresponding to the second task after the end-of-day file corresponding to the first task has been executed, and proceed to step S607.

[0096] S607, collects the first parameter information during the process of executing the end-of-day file corresponding to the first task;

[0097] S608, call and execute the end-of-day file corresponding to the second task;

[0098] S609, collecting second parameter information during the process of executing the end-of-day file corresponding to the second task;

[0099] S610, test exited.

[0100] It should be noted that the descriptions in S601-S610 above can be found in the relevant descriptions in the above embodiments, and their effects are similar, so they will not be repeated here.

[0101] Furthermore, regarding the project case testing methods provided in this application, combined with... Figure 7 The flowchart shown below provides a detailed explanation of the test case testing method for this project, which can be divided into three parts: pre-test execution, testing phase, and post-test execution. The pre-test execution phase involves: first, acquiring the test cases to be tested and determining if they are executable. If a test case is being invoked, the test exits; if not, collecting case information, the start time of the end-of-day file, test input information, test result information, and log information; sorting the test tasks according to the end-of-day sorting method; and then determining whether there is a conflict between the end-of-day sorting method and the default sorting method in Testng. If a conflict exists, the test exits; otherwise, the testing phase begins. The testing phase consists of the following steps: First, the method execution is monitored to determine if any system or data issues exist throughout the testing process. Then, tasks are divided into a first task and a second task based on their attributes. The existence of a first task is checked; if so, its conditions are met, and the first task's execution conditions are collected, along with its first parameter information. If the first task's conditions are not met, the information is collected. If no first task exists, the second task is executed, and its second parameter information is collected. After the test is completed, the first parameter information for the first task and the second parameter information for the second task are collected.

[0102] In the above project case testing method, the test cases to be tested are first obtained, and it is determined whether the test cases are in an idle state. If they are in an idle state, the test tasks are sorted according to their task identifiers to obtain sorted test tasks. Based on the task attribute information of each test task, the sorted test tasks are divided into a first task and a second task. The end-of-day file corresponding to the first task is called, and it is determined whether the execution time of the first task is consistent with the execution time of the end-of-day file corresponding to the first task. If they are consistent, the end-of-day file corresponding to the first task is executed. After the end-of-day file corresponding to the first task is completed, the end-of-day file corresponding to the second task is executed. The first parameter information during the execution of the end-of-day file corresponding to the first task is collected. The end-of-day file corresponding to the second task is called and executed, and the second parameter information during the execution of the end-of-day file corresponding to the second task is collected. The entire testing process is completed. By sorting the test tasks, common tasks are tested in a unified manner, which can save testing time and improve the efficiency of the testing process.

[0103] It should be understood that, although Figure 2-7 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2-7 At least some of the steps in the process may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0104] In one embodiment, such as Figure 8 As shown, a project case testing device is provided, including: a first acquisition module 11, a second acquisition module 12, and a testing module 13, wherein:

[0105] The first acquisition module 11 is used to acquire test cases; the test cases include at least two test tasks.

[0106] The second acquisition module 12 is used to divide each test task according to the task parameters of each test task to obtain the divided test tasks.

[0107] Test module 13 is used to call the end-of-day files corresponding to the divided test tasks and test the test cases of the project to be tested.

[0108] The project case testing device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0109] In one embodiment, such as Figure 9 As shown, the second acquisition module 12 includes: a sorting unit 121 and a partitioning unit 122, wherein:

[0110] The sorting unit 121 is used to sort the test tasks according to the task identifier of each test task to obtain the sorted test tasks.

[0111] The partitioning unit 122 is used to partition the sorted test tasks according to the task attribute information of each test task to obtain the first task and the second task; wherein the frame type to which the first task belongs is different from the frame type to which the second task belongs; the execution priority of the first task is higher than the execution priority of the second task.

[0112] Optionally, the task identifier of each test task is used to represent the execution order of each test task; the task attribute information of each test task includes the execution position of the subtasks in each test task.

[0113] The project case testing device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0114] In one embodiment, such as Figure 10 As shown, the test module 13 includes: a judgment unit 131 and a first execution unit 132, wherein:

[0115] The judgment unit 131 is used to call the end-of-day file corresponding to the first task and determine whether the execution time of the first task is consistent with the execution time of the end-of-day file corresponding to the first task.

[0116] The first execution unit 132 is used to execute the end-of-day file corresponding to the first task, and execute the end-of-day file corresponding to the second task after the end-of-day file corresponding to the first task has been executed.

[0117] The project case testing device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0118] In one embodiment, such as Figure 11 As shown, the test module 13 further includes: a second execution unit 133, wherein:

[0119] The second execution unit 133 is used to call and execute the end-of-day file corresponding to the second task.

[0120] The project case testing device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0121] In one embodiment, such as Figure 12 As shown, the test module 13 also includes: a data acquisition unit 134, wherein:

[0122] The acquisition unit 134 acquires the first parameter information during the execution of the end-of-day file corresponding to the first task and the second parameter information during the execution of the end-of-day file corresponding to the second task.

[0123] The project case testing device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0124] In one embodiment, such as Figure 13 As shown, the above-mentioned device further includes: a judgment module 14, wherein:

[0125] Module 14 is used to determine whether the test case is in an idle state.

[0126] The second acquisition module 12 mentioned above is used to divide each test task according to the task parameters of each test task when the test case is in an idle state, and obtain the divided test tasks.

[0127] The project case testing device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0128] Specific limitations regarding the project case testing device can be found in the limitations of the project case testing method described above, and will not be repeated here. Each module in the aforementioned project case testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0129] Those skilled in the art will understand that Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the server to which the solution of this application is applied. A specific server may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0130] In one embodiment, a server is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps:

[0131] Obtain test cases for projects to be tested; each test case should include at least two test tasks.

[0132] The test tasks are divided according to their parameters to obtain the divided test tasks.

[0133] Call the end-of-day file corresponding to the divided test tasks to test the test cases.

[0134] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0135] Obtain test cases for projects to be tested; each test case should include at least two test tasks.

[0136] The test tasks are divided according to their parameters to obtain the divided test tasks.

[0137] Call the end-of-day file corresponding to the divided test tasks to test the test cases.

[0138] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0139] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0140] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A project case testing method, characterized in that, The method includes: Obtain test cases for projects to be tested; each test case includes at least two test tasks. The test tasks are divided according to their task parameters to obtain the divided test tasks. Call the end-of-day file corresponding to the divided test tasks to test the test cases of the project to be tested; The step of dividing each test task according to the task parameters of each test task to obtain the divided test tasks includes: Based on the task identifier of each test task, sort the test tasks to obtain the sorted test tasks; Based on the task attribute information of each test task, the sorted test tasks are divided into a first task and a second task; wherein the frame type to which the first task belongs is different from the frame type to which the second task belongs, the first task is a test task executed in the pre-processing part of the test framework, and the second task is a test task executed in the main body of the test framework; the execution priority of the first task is higher than the execution priority of the second task. The step of calling the end-of-day file corresponding to the divided test tasks to test the test case includes: Call the end-of-day file corresponding to the first task and determine whether the execution time of the first task is consistent with the execution time of the end-of-day file corresponding to the first task; If so, execute the end-of-day file corresponding to the first task, and execute the end-of-day file corresponding to the second task if the end-of-day file corresponding to the first task has been executed. If the execution time of the first task is inconsistent with the execution time of the end-of-day file corresponding to the first task, then the end-of-day file corresponding to the second task is invoked and executed.

2. The method according to claim 1, characterized in that, The task identifier of each test task is used to characterize the execution order of each test task; the task attribute information of each test task includes the execution position of the subtasks in each test task.

3. The method according to claim 2, characterized in that, The method further includes: Collect first parameter information during the execution of the end-of-day file corresponding to the first task and second parameter information during the execution of the end-of-day file corresponding to the second task; the first parameter information includes the execution status information of the first task; the second parameter information includes the execution status information of the second task.

4. The method according to claim 1, characterized in that, Before dividing each test task according to its task parameters to obtain the divided test tasks, the method further includes: Determine whether the test case is in an idle state; If so, the test tasks are divided according to their task parameters to obtain the divided test tasks.

5. A project case testing device, characterized in that, The apparatus, applied to the project case testing method as described in claim 1, comprises: The first acquisition module is used to acquire test cases; the test cases include at least two test tasks. The second acquisition module is used to divide each test task according to the task parameters of each test task to obtain the divided test tasks. The testing module is used to call the end-of-day files corresponding to the divided test tasks and test the test cases of the project to be tested. The second acquisition module includes: The sorting unit is used to sort the test tasks according to the task identifier of each test task to obtain the sorted test tasks. A partitioning unit is used to partition the sorted test tasks according to the task attribute information of each test task to obtain a first task and a second task; wherein the frame type to which the first task belongs is different from the frame type to which the second task belongs, the first task is a test task executed in the front part of the test framework, and the second task is a test task executed in the main part of the test framework; the execution priority of the first task is higher than the execution priority of the second task.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images