Forced waiting-based interface test method, device, equipment and medium

Abstract

This invention provides an interface testing method, apparatus, device, and medium based on forced waiting, including: acquiring multiple preset test cases for interface testing; creating a first thread, sequentially testing the multiple test cases in the first thread, and generating corresponding test data; determining whether the test case currently being tested in the first thread triggers forced waiting; if forced waiting is triggered, locking the currently testing first thread for a preset time, creating a second thread, and sequentially testing all other test cases in the second thread, generating corresponding test data; if forced waiting is not triggered, continuing to test the unfinished test cases in the currently testing first thread. This invention can effectively shorten interface testing time and improve interface testing efficiency.

Description

Technical Field

[0001] This invention relates to the field of development and testing technology, and in particular to interface testing methods, apparatus, equipment and media based on forced wait. Background Technology

[0002] Interface automation (IA) is a testing method that uses written test cases to perform tests. Test cases execute test tasks, simulating a user's request chain to initiate an interface request. The server accepts the request and returns a result. By comparing the returned result with the expected result, the functionality of the interface can be verified.

[0003] Currently, when executing automated test cases, it is sometimes necessary to wait for page elements to load and data to be returned. Testing cannot be performed during this process, thus extending the interface testing time and reducing its efficiency. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide an interface testing method, apparatus, device and medium based on forced waiting, which can improve the efficiency of interface testing.

[0005] To achieve the above and other related objectives, this invention provides an interface testing method based on forced waiting, comprising:

[0006] Obtain multiple pre-defined test cases for the interface test;

[0007] Create a first thread, and test multiple test cases sequentially in the first thread to generate corresponding test data;

[0008] Determine whether the test case currently being tested in the first thread triggers a forced wait;

[0009] If a forced wait is triggered, the first thread of the current test is locked for a preset time, a second thread is created, and all other test cases are tested in sequence in the second thread to generate the corresponding test data; if a forced wait is not triggered, the unfinished test cases continue to be tested in the first thread of the current test.

[0010] When the preset time expires, the second thread currently being tested is locked, and the first thread is tested again.

[0011] Repeatedly check whether the current test case triggers a forced wait until the test completes multiple test cases;

[0012] Summarize the test data from all threads to generate a test report.

[0013] In one embodiment of the present invention, the step of obtaining a plurality of preset test cases for interface testing includes:

[0014] Based on the target test task of the interface test, create multiple test cases.

[0015] In one embodiment of the present invention, the step of creating a first thread, sequentially testing multiple test cases in the first thread, and generating corresponding test data includes:

[0016] Create a first thread, and test multiple test cases sequentially in the first thread;

[0017] Obtain the test log information, thread number, and test results of the first thread to generate test data for the thread.

[0018] In one embodiment of the present invention, the step of locking the first thread of the current test within a preset time and creating a second thread if forced waiting is triggered, and then testing all other test cases in the second thread in sequence, includes:

[0019] If a forced wait is triggered, the first thread of the current test is locked, a second thread is created, and all other test cases are tested in the second thread in sequence.

[0020] Create a process to execute a timing task to record the locking time of the first thread that is currently locked.

[0021] In one embodiment of the present invention, the step of creating a second thread, sequentially testing all other test cases in the second thread, and generating corresponding test data includes:

[0022] Create a second thread, and test all other test cases in the second thread in sequence;

[0023] Obtain the log information, thread number, and test results of the second thread to generate test data for that thread.

[0024] In one embodiment of the present invention, the step of locking the currently tested second thread and continuing to test the first thread after the preset time has ended includes:

[0025] Determine whether the current locking time of the first thread is greater than the preset time of the timed task;

[0026] If the lock time of the first thread is greater than or equal to the preset time of the timing task, lock the second thread currently being tested, and continue testing the first thread;

[0027] If the locking time of the first thread is less than the preset time of the timed task, the first thread will continue to be locked.

[0028] In one embodiment of the present invention, the step of locking the second thread currently being tested and continuing to test the first thread when the locking time of the first thread is greater than or equal to the preset time of the timing task includes:

[0029] If the lock time of the first thread is greater than or equal to the preset time of the timed task, lock the second thread of the current test;

[0030] Stop locking the first thread that was previously locked, and continue testing the first thread until the test of the thread is completed;

[0031] Continue testing the second thread.

[0032] The present invention also provides an interface testing apparatus based on forced wait, comprising:

[0033] The acquisition module is used to acquire multiple pre-defined test cases for interface testing;

[0034] The testing module is used to create a first thread, in which multiple test cases are tested sequentially and corresponding test data is generated. If a forced wait is triggered, the first thread currently being tested is locked for a preset time, and a second thread is created. In the second thread, all other test cases are tested sequentially and corresponding test data is generated. If a forced wait is not triggered, the unfinished test cases are tested in the first thread currently being tested. The module is also used to lock the second thread currently being tested when the preset time expires and continue testing the first thread.

[0035] The judgment module is used to repeatedly judge whether the test case in the current test triggers forced waiting, until the test completes multiple test cases;

[0036] The summary module is used to summarize the test data of all threads to generate a test report.

[0037] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described interface testing method based on forced wait.

[0038] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the interface testing method based on forced wait described above.

[0039] As described above, the present invention provides an interface testing method, apparatus, device, and medium based on forced waiting, which can effectively shorten interface testing time and improve interface testing efficiency. Attached Figure Description

[0040] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 The diagram shows an application environment of the interface testing method based on forced waiting according to the present invention.

[0042] Figure 2 The diagram shows a flowchart of an interface testing method based on forced waiting in one embodiment of the present invention.

[0043] Figure 3 This is a schematic diagram of an exemplary process for multi-threaded alternating testing;

[0044] Figure 4 Displayed as Figure 2 A schematic diagram of a specific implementation method for step S20;

[0045] Figure 5 Displayed as Figure 2 A schematic diagram of a specific implementation of step S40;

[0046] Figure 6 Displayed as Figure 5 A flowchart illustrating another specific implementation of step S41;

[0047] Figure 7 Displayed as Figure 2 A schematic diagram of a specific implementation method for step S50;

[0048] Figure 8 This is a schematic diagram of an interface testing device based on forced waiting in one embodiment of the present invention;

[0049] Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0050] Figure 10 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] Please see Figure 1-10 It should be noted that the illustrations provided in this embodiment are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0053] The interface testing method based on forced waiting provided in this invention can be applied to applications such as... Figure 1 In this application environment, client 110 communicates with server 120 via a network. When developers need to perform automated interface testing, they can pre-set the target tasks for interface testing on their client 110. During testing, server 120 can obtain the pre-set target tasks for interface testing from client 110, and write multiple test cases based on these tasks. Then, server 120 can create a first thread based on a pre-set test order, and test multiple test cases sequentially within the first thread. During testing, it can be determined whether the currently tested test case triggers a forced wait. If a forced wait is triggered, the first thread is locked for a preset time, and a second thread is created to test all other test cases. If no forced wait is triggered, the first thread continues testing the unfinished test cases. When the preset time ends, the second thread is locked, and the previously locked first thread is released for testing. Then, it is determined again whether the test cases in the first thread trigger a forced wait. If a forced wait is triggered, the first thread is locked again, and the test cases in the second thread continue testing. This process is repeated until all test cases are completed. Finally, the test data from all threads is summarized to generate a test report. This report can be transmitted to the developer's client (110) for analysis of issues encountered during interface testing. This invention effectively shortens interface testing time and improves testing efficiency. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster. The invention will be described in detail below through specific embodiments.

[0054] Please see Figure 2 As shown, Figure 2 A flowchart illustrating an interface testing method based on forced waiting provided in an embodiment of the present invention includes the following steps:

[0055] Step S10: Obtain multiple pre-set test cases for interface testing;

[0056] Step S20: Create a first thread, and test multiple test cases sequentially in the first thread to generate corresponding test data;

[0057] Step S30: Determine whether the test case currently being tested in the first thread triggers a forced wait;

[0058] Step S40: If forced waiting is triggered, lock the first thread of the current test within a preset time, create a second thread, test all other test cases in the second thread in sequence, and generate corresponding test data; if forced waiting is not triggered, continue testing the unfinished test cases in the first thread of the current test.

[0059] Step S50: When the preset time ends, lock the second thread currently being tested and continue testing the first thread;

[0060] Step S60: Repeatedly determine whether the test case of the current test triggers forced waiting, until the test completes multiple test cases;

[0061] Step S70: Summarize the test data of all threads to generate a test report.

[0062] Regarding step S10, it should be noted that the preset interface test can be an automated interface test. Based on the automated interface test task, test cases can be written to test the interface status. Test cases can refer to test tasks. During each test case test, the server 120 initiates an interface request by simulating the request chain of the user end. The server accepts the request and returns the result to the server 120. By comparing whether the returned result is consistent with the expected result, the normality of the interface can be verified.

[0063] As an example, in the order business scenario, test cases can be written based on each step of the order business process. For instance, the order business might have interfaces for submitting an order and for making a payment. For the order submission interface, corresponding test cases can be written to test whether the interface functions correctly. Similarly, for the payment page interface, corresponding test cases can be written to test whether the interface functions correctly. In the order business scenario, multiple test cases can be used to test multiple interfaces of the business.

[0064] When conducting interface testing, multiple test cases can be written based on the interface's testing requirements. It's important to note that test cases can include positive and negative test cases. Positive test cases refer to inputs supported by the system, while negative test cases refer to inputs not supported by the system. For example, if an input only accepts numbers 2-9, positive test cases could include 2, 3, 4, 5, 6, 7, 8, and 9. Testing positive test cases allows you to check if the interface can provide the expected feedback. Negative test cases can include other values, such as 0, 1, and 0.1. Testing negative test cases allows you to check if the interface can detect abnormal inputs.

[0065] Regarding step S20, it should be noted that when testing multiple test cases, they can be prioritized and tested in a certain order. For example, multiple test cases can be divided into positive and negative test cases. Positive test cases can be tested first to check the basic functionality of the interface under normal input. Next, negative test cases can be tested to check whether the interface will generate an error when abnormal input occurs. The priority of test cases can be set such that positive test cases have a higher priority than negative test cases, and test the higher-priority test cases first.

[0066] It's important to further clarify that when testing positive test cases, the interfaces can be ordered according to their functionality and tested in a specific order. For example, in positive test cases for order processing, there might be interfaces for querying orders, submitting orders, and making payments. Based on the importance of each interface's functionality, the payment page interface could be prioritized over the order submission page interface, and the order submission page interface could be prioritized over the order query interface. Therefore, when testing positive test cases, the payment page interface can be tested first, followed by the order submission page interface, and finally the order query interface. Similarly, when testing negative test cases, the interfaces can be ordered according to their functionality and tested in a specific order.

[0067] It's worth mentioning that test cases can be executed via threads. Multiple test cases can be executed sequentially within a single thread. It should be noted that a thread can refer to a unit of execution.

[0068] Regarding step S30, it should be noted that when executing test cases, sometimes the page is still loading after an interface request is initiated. If the page element has not yet appeared, the returned element information cannot be located, and this test case will generate an error message. To avoid unnecessary error messages, a forced wait can be invoked, forcing the test case to wait for a preset time. This preset time is greater than the page element loading time, ensuring that the returned element information can be located after the forced wait, thus avoiding unnecessary error messages. However, during the forced wait, the entire thread cannot continue testing, resulting in wasted time. To improve the execution efficiency of test cases, when executing a test case, it can be determined whether the test case triggers a forced wait, and if a forced wait is triggered, other test cases can be tested.

[0069] In step S40, if a forced wait is triggered during the execution of a test case, the first thread of the current test is locked for a preset time to prevent it from continuing to test this test case. Then, a second thread can be created to test all other test cases, avoiding unnecessary waiting time in the first thread and improving interface testing efficiency. If no forced wait is triggered during the testing of this test case, incomplete test cases can continue to be tested. When the locking time of the first thread expires, for example, when the page in the test case has finished loading, the second thread can be locked, released, and the first thread can continue testing.

[0070] Regarding step S50, it should be noted that when a forced wait is triggered, the first thread is locked for a preset time, and a second thread is created to test other test cases. When the preset time ends, the second thread is locked, and testing of the first thread continues. When a test case in the first thread triggers a forced wait again, the first thread can be locked again, and the second thread can be released to continue testing. This alternating testing allows the test cases in the first thread to complete execution, and then other test cases in the second thread can continue to be executed.

[0071] It is worth noting that if a forced wait is triggered while testing test cases in the second thread, the second thread can be locked again within a preset time, a third thread can be created, and all other test cases can be executed. Then, switch threads in the same way as above, alternating between them, until all test cases are completed.

[0072] For step S60, as Figure 3As shown in the example, for an interface testing task, four test cases A, B, C, and D can be set, with their test order predetermined. Then, the first thread S1 is started to test test cases A, B, C, and D sequentially. When test case A triggers a forced wait, the first thread S1 is locked for a preset time, keeping test case A in a forced wait state. The second thread S2 is then started to test test cases B, C, and D sequentially. If the forced wait in the first thread S1 ends while the second thread S2 is executing test case B, the first thread S1 can be released and testing can continue, while the second thread S2 is locked. If test case A in the first thread S1 triggers a forced wait again, the first thread S1 is locked again for a preset time, keeping test case A in a forced wait state, while testing test case B in the second thread S2 continues. If the second thread S2 does not encounter a forced wait and executes to test case C, and the forced wait in the first thread S1 ends again, the first thread S1 is released and testing resumes, while the second thread S2 is locked. This process continues alternately until the first thread S1 is completed. Then, test case C in the second thread S2 is tested. When test case C in the second thread S2 triggers a forced wait, the third thread S3 is started and the same steps are repeated until all test cases have been tested.

[0073] It should be noted that the test order of all the above test cases can be set based on the test requirements.

[0074] Regarding step S70, it should be noted that after all test cases have been tested, the test data of the test cases in each thread can be summarized to generate a test report, which can be used by developers to analyze the problems existing in the interface.

[0075] It needs further explanation that test data can include the test results of each test case, test log information for each thread, and the thread number. Test log information can include the interface type, request address, request parameters, response time, error messages, and return information for each test case in each thread. The test results show whether the test case results are as expected. The log information provides detailed test information for all test cases in each thread, allowing developers to analyze potential problems with the interface.

[0076] In one exemplary embodiment, the process of obtaining multiple test cases for a preset interface test may include obtaining multiple test cases based on the target test task of the interface test.

[0077] It's important to note that different target test tasks can be set for different interface testing scenarios. For example, in an order business scenario, you can test the interface for the order submission page, the payment page, or other test tasks, thus allowing you to write multiple test cases. Different test cases can be written for different interface testing needs. For instance, if you need to test the basic functionality of the interface under normal input, you can write positive test cases. If you need to test whether the interface will generate errors under abnormal input, you can write negative test cases.

[0078] In one exemplary embodiment, such as Figure 4 As shown, the process of creating a first thread, sequentially testing multiple test cases in the first thread, and generating corresponding test data may include,

[0079] Step S21: Create a first thread and test multiple test cases sequentially in the first thread.

[0080] Step S22: Obtain the test log information, thread number, and test results of the first thread to generate test data for that thread.

[0081] It should be noted that when creating a thread to test multiple test cases, a thread S1 can be created. Thread S1 can be configured to test four test cases A, B, C, and D sequentially. During the testing process, log information, thread IDs, and test results can be recorded. This allows developers to analyze any issues that occurred during the testing of the test cases within the thread, based on the log information, thread IDs, and test results.

[0082] It's worth further elaboration that log information can include the interface type, request address, request parameters, response time, error messages, and return information for each test case within a thread, providing a detailed reflection of the test case's performance. The thread number is a unique identifier representing the thread; this identifier can be a single number, letter, or symbol, or a combination of numbers, letters, and symbols. When multiple threads are created in a test task, the thread number can be used to distinguish between different threads.

[0083] In one exemplary embodiment, such as Figure 5 As shown, if a forced wait is triggered, the first thread of the current test is locked within a preset time, a second thread is created, and the process of testing all other test cases in the second thread in sequence may include:

[0084] Step S41: If forced waiting is triggered, lock the first thread of the current test, create a second thread, and test all other test cases in the second thread in sequence.

[0085] Step S42: Create a process to execute a timing task to record the locking time of the currently locked first thread.

[0086] It should be noted that when a test case in the first thread triggers a forced wait, to avoid wasting unnecessary waiting time, the first thread can be locked, and a second thread can be created to test all other test cases. When creating the second thread, an initial process can be created simultaneously to start a timer and record the locking time of the first thread. When the locking time is greater than or equal to a preset time, the forced wait of the first thread ends, and the first thread can be released and testing can continue, while the second thread is locked.

[0087] It needs further explanation that a process can be an executable program that performs timing tasks. Processes and threads execute independently; processes are used to perform timing tasks, while threads are used to execute test cases.

[0088] In one exemplary embodiment, such as Figure 6 As shown, the process of creating a second thread, testing all other test cases sequentially in the second thread, and generating corresponding test data may include:

[0089] Step S411: Create a second thread and test all other test cases in the second thread in sequence.

[0090] Step S412: Obtain the log information, thread number, and test results of the second thread to generate test data for that thread.

[0091] It should be noted that when a test case in the first thread triggers a forced wait, in order to avoid wasting unnecessary waiting time, the first thread of the current test can be locked, and a second thread can be created to test all other test cases.

[0092] When testing in the second thread, log information, thread number, and test results of test cases can be recorded during the testing process. This allows developers to analyze problems that occurred during the testing of test cases in the second thread based on the log information, thread number, and test results.

[0093] It's worth further elaboration that log information can include the interface type, request address, request parameters, response time, error messages, and return information for each test case within a thread, providing a detailed reflection of the test case's performance. The thread number is a unique identifier representing the thread; this identifier can be a single number, letter, or symbol, or a combination of numbers, letters, and symbols. When multiple threads are created in a test task, the thread number can be used to distinguish between different threads.

[0094] In one exemplary embodiment, such as Figure 7As shown, when the preset time expires, the process of locking the second thread currently being tested and continuing to test the first thread may include:

[0095] Step S51: Determine whether the locking time of the currently locked first thread is greater than the preset time of the timing task;

[0096] Step S52: When the locking time of the first thread is greater than or equal to the preset time of the timing task, lock the second thread currently being tested and continue testing the first thread;

[0097] Step S53: When the locking time of the first thread is less than the preset time of the timing task, continue to lock the first thread.

[0098] It's important to note that when a test case in the first thread triggers a forced wait, to avoid wasting unnecessary waiting time, the first thread can be locked, and a second thread can be created to test all other test cases. When creating the second thread, an initial process can be created simultaneously to start timing and record the locking time of the first thread. When the locking time is greater than or equal to the preset time of the timing task, the forced wait of the first thread ends, and the first thread can be released and testing can continue, while the second thread is locked. After the first thread completes its test, the second thread can be released and testing can continue. When the locking time is less than the preset time of the timing task, the currently locked first thread remains locked. Using this alternating testing method can avoid wasting unnecessary waiting time and improve testing efficiency.

[0099] It is worth mentioning that the preset time of the timing task is greater than or equal to the forced wait time, ensuring that when the locked thread is released, the forced wait of the test cases in the thread has ended and the test can continue.

[0100] It should be noted that multiple threads may be created during the testing process. For example, the first thread S1 tests test case A, the second thread S2 tests test cases B and C, and the third thread S3 tests test case D. After all test cases have been tested, the test results of the test cases in each thread, the log information of each thread, and the thread number can be summarized to generate a test report, which developers can use to analyze the problems existing in the interface.

[0101] Log information can include the interface type, request address, request parameters, response time, error messages, and return information for each test case in each thread. Log information provides detailed test information for all test cases in each thread. Test results show whether the test case results are as expected. The thread ID identifies the thread corresponding to each test result. Each thread has a corresponding thread ID, log information, and test result; developers can quickly analyze test results based on the log information of a given test case's result.

[0102] As can be seen, the above solution can effectively shorten the interface testing time and improve the efficiency of interface testing.

[0103] It should be understood that the sequence number of each step in the above embodiments does not imply 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 embodiments of the present invention.

[0104] In one embodiment, a forced-wait-based interface testing apparatus is provided, which corresponds one-to-one with the forced-wait-based interface testing methods described in the above embodiments. For example... Figure 8 As shown, the interface testing device based on forced waiting includes an acquisition module 101, a testing module 102, a judgment module 103, and a summarization module 104.

[0105] In one embodiment, the acquisition module 101 can be used to acquire multiple test cases for a preset interface test. Specifically, the acquisition module 101 can be used to create multiple test cases based on the target test task of the interface test.

[0106] In one embodiment, the testing module 102 can be used to create a first thread, in which multiple test cases are tested sequentially to generate corresponding test data. Specifically, the testing module 102 can be used to create a first thread, in which multiple test cases are tested sequentially, and to obtain the test log information, thread number, and test results of the first thread to generate the test data of the thread.

[0107] In one embodiment, the test module 102 can also be used to, if a forced wait is triggered, lock the first thread currently being tested within a preset time, create a second thread, and sequentially test all other test cases in the second thread to generate corresponding test data. If a forced wait is not triggered, continue testing the unfinished test cases in the first thread currently being tested. Specifically, the test module 102 can also be used to, if a forced wait is triggered, lock the first thread currently being tested, create a second thread, sequentially test all other test cases in the second thread, and create a process to execute a timing task to record the locking time of the currently locked first thread. The test module 102 can also be specifically used to create a second thread, sequentially test all other test cases in the second thread, obtain the log information, thread number, and test results of the second thread, and generate test data for that thread.

[0108] In one embodiment, the testing module 102 can also be used to lock the currently tested second thread and continue testing the first thread when the preset time ends. Specifically, the testing module 102 can also be used to determine whether the locking time of the currently locked first thread is greater than the preset time of the timing task. If the locking time of the first thread is greater than or equal to the preset time of the timing task, the currently tested second thread is locked, and testing of the first thread continues. If the locking time of the first thread is less than the preset time of the timing task, the first thread remains locked. Further, the testing module 102 can also be used to lock the currently tested second thread when the locking time of the first thread is greater than or equal to the preset time of the timing task, stop locking the previously locked first thread, and continue testing the first thread until the thread test is completed, then continue testing the second thread.

[0109] In one embodiment, the determination module 103 can be used to repeatedly determine whether the thread currently being tested has triggered a forced wait until the test completes multiple test cases.

[0110] In one embodiment, the aggregation module 104 can be used to aggregate test data from all threads to generate a test report.

[0111] This invention provides an interface testing device based on forced waiting, which can effectively shorten the interface testing time and improve the interface testing efficiency.

[0112] Specific limitations regarding the interface testing device based on forced waiting can be found in the limitations of the interface testing method based on forced waiting mentioned above, and will not be repeated here. Each module in the aforementioned intelligent question-answering processing 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 corresponding operations of each module.

[0113] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external user terminals via a network connection. When the computer program is executed by the processor, it implements the functions or steps of the server-side interface testing method based on forced wait.

[0114] In one embodiment, a computer device is provided, which may be a user terminal, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices 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 and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the user side of the interface testing method based on forced wait.

[0115] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0116] Obtain multiple pre-defined test cases for the interface test;

[0117] Create a first thread, and test multiple test cases sequentially in the first thread to generate corresponding test data;

[0118] Determine whether the test case currently being tested in the first thread triggers a forced wait;

[0119] If a forced wait is triggered, the first thread of the current test is locked for a preset time, a second thread is created, and all other test cases are tested in sequence in the second thread to generate the corresponding test data; if a forced wait is not triggered, the unfinished test cases continue to be tested in the first thread of the current test.

[0120] When the preset time expires, the second thread currently being tested is locked, and the first thread is tested again.

[0121] Repeatedly check whether the current test case triggers a forced wait until the test completes multiple test cases;

[0122] Summarize the test data from all threads to generate a test report.

[0123] 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:

[0124] Obtain multiple pre-defined test cases for the interface test;

[0125] Create a first thread, and test multiple test cases sequentially in the first thread to generate corresponding test data;

[0126] Determine whether the test case currently being tested in the first thread triggers a forced wait;

[0127] If a forced wait is triggered, the first thread of the current test is locked for a preset time, a second thread is created, and all other test cases are tested in sequence in the second thread to generate the corresponding test data; if a forced wait is not triggered, the unfinished test cases continue to be tested in the first thread of the current test.

[0128] When the preset time expires, the second thread currently being tested is locked, and the first thread is tested again.

[0129] Repeatedly check whether the current test case triggers a forced wait until the test completes multiple test cases;

[0130] Summarize the test data from all threads to generate a test report.

[0131] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and user side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0132] 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, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0133] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to 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.

[0134] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method of interface testing based on forced waiting, characterized in that, include: Obtain multiple pre-defined test cases for the interface test; Create a first thread, and test multiple test cases sequentially in the first thread to generate corresponding test data; Determine whether the test case currently being tested in the first thread triggers a forced wait; If a forced wait is triggered, the first thread of the current test is locked for a preset time, a second thread is created, and all other test cases are tested in sequence in the second thread to generate the corresponding test data; if a forced wait is not triggered, the unfinished test cases continue to be tested in the first thread of the current test. Determine whether the current locking time of the first thread is greater than the preset time of the timed task; If the locking time of the first thread is greater than or equal to the preset time of the timing task, lock the second thread currently being tested; stop locking the previously locked first thread, and continue testing the first thread until the test of that thread is completed; Continue testing the second thread; If the locking time of the first thread is less than the preset time of the timed task, the first thread will continue to be locked; Repeatedly check whether the current test case triggers a forced wait until the test completes multiple test cases; Summarize the test data from all threads to generate a test report.

2. The forced-wait based interface testing method of claim 1, wherein, The steps for obtaining multiple pre-set test cases for interface testing include: Based on the target test task of the interface test, create multiple test cases.

3. The interface testing method based on forced waiting according to claim 1, characterized in that, The steps of creating a first thread, sequentially testing multiple test cases in the first thread, and generating corresponding test data include: Create a first thread, and test multiple test cases sequentially in the first thread; Obtain the test log information, thread number, and test results of the first thread to generate test data for that thread.

4. The interface testing method based on forced waiting according to claim 1, characterized in that, The steps of locking the first thread of the current test within a preset time and creating a second thread if a forced wait is triggered, and then testing all other test cases in the second thread in sequence, include: If a forced wait is triggered, the first thread of the current test is locked, a second thread is created, and all other test cases are tested in the second thread in sequence. Create a process to execute a timing task to record the locking time of the first thread that is currently locked.

5. The interface testing method based on forced waiting according to claim 1, characterized in that, The steps of creating a second thread, testing all other test cases sequentially in the second thread, and generating corresponding test data include: Create a second thread, and test all other test cases in the second thread in sequence; Obtain the log information, thread number, and test results of the second thread to generate test data for that thread.

6. An interface testing device based on forced waiting, characterized in that, The interface testing apparatus, which uses the forced wait-based interface testing method as described in any one of claims 1 to 5, comprises: The acquisition module is used to acquire multiple pre-defined test cases for interface testing; The testing module is used to create a first thread, in which multiple test cases are tested sequentially and corresponding test data is generated. If a forced wait is triggered, the first thread currently being tested is locked for a preset time, and a second thread is created. In the second thread, all other test cases are tested sequentially and corresponding test data is generated. If a forced wait is not triggered, the unfinished test cases are tested in the first thread currently being tested. The module is also used to lock the second thread currently being tested when the preset time expires and continue testing the first thread. The judgment module is used to repeatedly judge whether the test case in the current test triggers forced waiting, until the test completes multiple test cases; The summary module is used to summarize the test data of all threads to generate a test report.

7. A computer 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, it implements the steps of the interface testing method based on forced waiting as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the interface testing method based on forced wait as described in any one of claims 1 to 5.

Images