CN116049004A - Interface testing method, device, equipment and medium based on forced waiting - Google Patents
Interface testing method, device, equipment and medium based on forced waiting Download PDFInfo
- Publication number
- CN116049004A CN116049004A CN202310090588.3A CN202310090588A CN116049004A CN 116049004 A CN116049004 A CN 116049004A CN 202310090588 A CN202310090588 A CN 202310090588A CN 116049004 A CN116049004 A CN 116049004A
- Authority
- CN
- China
- Prior art keywords
- thread
- test
- testing
- interface
- locking
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides an interface test method, device, equipment and medium based on forced waiting, which comprises the steps of obtaining a plurality of test cases of a preset interface test; creating a first thread, and sequentially testing a plurality of test cases in the first thread to generate corresponding test data; judging whether the test case currently tested in the first thread triggers forced waiting or not; if the forced waiting is triggered, locking the first thread currently tested in a preset time, creating a second thread, and sequentially testing all other test cases in the second thread to generate corresponding test data; if the forced waiting is not triggered, continuing to test the unfinished test cases in the first thread tested currently. The invention can effectively shorten the interface test time and improve the interface test efficiency.
Description
Technical Field
The present invention relates to the field of development testing technologies, and in particular, to a method, an apparatus, a device, and a medium for testing an interface based on forced waiting.
Background
Interface automation is a test method that tests through written test cases. The test case can execute a test task, when in test, an interface request is initiated through a request link of the simulation user terminal, the server receives the request and returns a result, and whether the interface is normal can be verified by comparing whether the returned result is consistent with an expected result or not.
Currently, when an automated test case is executed, it is sometimes necessary to wait for loading of page elements, return of data, and the like. In the process, the test cannot be performed, so that the interface test time is prolonged, and the interface test efficiency is reduced.
Disclosure of Invention
In view of the above-mentioned drawbacks of the prior art, an object of the present invention is to provide a method, apparatus, device and medium for testing an interface based on forced waiting, which can improve the efficiency of testing an interface.
To achieve the above and other related objects, the present invention provides a forced wait based interface test method, comprising:
acquiring a plurality of test cases of a preset interface test;
creating a first thread, and sequentially testing a plurality of test cases in the first thread to generate corresponding test data;
judging whether the test case currently tested in the first thread triggers forced waiting or not;
if the forced waiting is triggered, locking the first thread currently tested in a preset time, creating a second thread, and sequentially testing all other test cases in the second thread to generate corresponding test data; if the forced waiting is not triggered, continuing to test the unfinished test cases in the first thread tested currently;
when the preset time is over, locking the second thread which is currently tested, and continuing to test the first thread;
repeatedly judging whether the currently tested test case triggers forced waiting or not until the test is completed on a plurality of test cases;
the test data for all threads is aggregated to generate a test report.
In an embodiment of the present invention, the step of obtaining a plurality of test cases of a preset interface test includes:
and creating a plurality of test cases based on the target test task of the interface test.
In an embodiment of the present invention, the creating a first thread, testing a plurality of test cases in the first thread in turn, and generating corresponding test data includes:
creating a first thread, and sequentially testing a plurality of test cases in the first thread;
and acquiring the test log information, the thread number and the test result of the first thread to generate test data of the thread.
In an embodiment of the present invention, if the forced waiting is triggered, locking the first thread currently tested in a preset time, creating a second thread, and sequentially testing all other test cases in the second thread includes:
if the forced waiting is triggered, locking the first thread tested currently, creating a second thread, and sequentially testing all other test cases in the second thread;
the creation process performs a timing task to record the lock time of the first thread currently locked.
In an embodiment of the present invention, the creating a second thread, testing all other test cases in the second thread in turn, and generating corresponding test data includes:
creating a second thread, and sequentially testing all other test cases in the second thread;
and acquiring log information, a thread number and a test result of the second thread to generate test data of the thread.
In an embodiment of the present invention, when the preset time is over, locking the second thread currently tested, and continuing to test the first thread includes:
judging whether the locking time of the first thread which is currently locked is longer than the preset time of a timing task or not;
when the locking time of the first thread is greater than or equal to the preset time of the timing task, locking the second thread which is currently tested, and continuing to test the first thread;
and continuously locking the first thread when the locking time of the first thread is smaller than the preset time of the timing task.
In an embodiment of the present invention, when the locking time of the first thread is greater than or equal to the preset time of the timing task, locking the second thread currently tested, and continuing to test the first thread includes:
when the locking time of the first thread is greater than or equal to the preset time of the timing task, locking the second thread which is currently tested;
stopping locking the first thread locked last, and continuing to test the first thread until the thread test is completed;
and continuing to test the second thread.
The invention also provides an interface testing device based on forced waiting, which comprises:
the acquisition module is used for acquiring a plurality of test cases of a preset interface test;
the testing module is used for creating a first thread, sequentially testing a plurality of test cases in the first thread, generating corresponding testing data, locking the first thread tested currently in preset time if forced waiting is triggered, creating a second thread, sequentially testing all other test cases in the second thread, generating corresponding testing data, continuously testing unfinished test cases in the first thread tested currently if forced waiting is not triggered, and locking the second thread tested currently when the preset time is over, and continuously testing the first thread;
the judging module is used for repeatedly judging whether the test case tested currently triggers forced waiting or not until the test is completed on a plurality of test cases;
and the summarizing module is used for summarizing the test data of all threads to generate a test report.
The invention also provides a computer device comprising a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein the processor realizes the steps of the interface testing method based on forced waiting when executing the computer program.
The present invention also provides a computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of the forced wait based interface test method described above.
As described above, the invention provides the interface test method, the device, the equipment and the medium based on forced waiting, which can effectively shorten the interface test time and improve the interface test efficiency.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of an application environment of a forced wait-based interface test method according to the present invention;
FIG. 2 is a flow chart of an interface testing method based on forced waiting according to an embodiment of the invention;
FIG. 3 is a schematic diagram of an exemplary flow of a multi-threaded alternating test;
FIG. 4 is a flowchart illustrating the step S20 in FIG. 2;
FIG. 5 is a flowchart illustrating the step S40 in FIG. 2;
FIG. 6 is a flowchart illustrating a step S41 of FIG. 5;
FIG. 7 is a flowchart of the step S50 in FIG. 2;
FIG. 8 is a schematic diagram of an interface testing apparatus based on forced waiting according to an embodiment of the present invention;
FIG. 9 is a schematic diagram of a computer device according to an embodiment of the invention;
fig. 10 is a schematic diagram of another configuration of a computer device according to an embodiment of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Please refer to fig. 1-10. It should be noted that, the illustrations provided in the present embodiment merely illustrate the basic concept of the present invention by way of illustration, and only the components related to the present invention are shown in the drawings and are not drawn according to the number, shape and size of the components in actual implementation, and the form, number and proportion of the components in actual implementation may be arbitrarily changed, and the layout of the components may be more complex.
The interface testing method based on forced waiting provided by the embodiment of the invention can be applied to an application environment as shown in fig. 1, wherein a user terminal 110 communicates with a server terminal 120 through a network. When the developer needs to perform the automated interface test, the target task of the interface test may be preset on the user terminal 110. When testing, the server 120 may obtain a target task of a preset interface test from the client 110, and may write a plurality of test cases based on the target task. Then, the server 120 may create a first thread based on a preset test sequence, and test a plurality of test cases in the first thread sequentially. When testing is carried out, whether the test case of the current test triggers forced waiting or not can be judged, if the forced waiting is triggered, the first thread of the current test is locked in a preset time, all other test cases of the second thread are created, and if the forced waiting is not triggered, the first thread of the current test continues to test the unfinished test cases. And when the preset time is over, locking the second thread which is currently tested, and releasing the first thread which is locked last for testing. And then judging whether the test case in the first thread tested at present triggers forced waiting or not, if so, locking the first thread at present again, and continuing to test the test case of the second thread. And (5) testing is circulated until testing is completed for a plurality of test cases. And finally summarizing the test data of all threads to generate a test report. The test report may be transmitted to the developer's user side 110 for the developer to analyze the problem in the interface test. In the invention, aiming at the interface test process, the interface test time can be effectively shortened, and the interface test efficiency can be improved. The user terminal may be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices. The server may be implemented by a stand-alone server or a server cluster formed by a plurality of servers. The present invention will be described in detail with reference to specific examples.
Referring to fig. 2, fig. 2 is a flow chart of a forced waiting-based interface testing method according to an embodiment of the invention, which includes the following steps:
step S10, acquiring a plurality of test cases of a preset interface test;
step S20, creating a first thread, and sequentially testing a plurality of test cases in the first thread to generate corresponding test data;
step S30, judging whether the test case currently tested in the first thread triggers forced waiting or not;
step S40, if the forced waiting is triggered, locking the first thread currently tested in a preset time, creating a second thread, and sequentially testing all other test cases in the second thread to generate corresponding test data; if the forced waiting is not triggered, continuing to test the unfinished test cases in the first thread tested currently;
step S50, locking the second thread tested currently and continuing to test the first thread when the preset time is over;
step S60, repeatedly judging whether the currently tested test case triggers forced waiting or not until the test is completed on a plurality of the test cases;
and step S70, summarizing test data of all threads to generate a test report.
For step S10, it should be noted that the preset interface test may be an automated interface test, and the writing of the test case may test the interface state based on the automated interface test task. The test cases may refer to test tasks, when each test case is tested, the server 120 initiates an interface request through a request link of the simulation user terminal, the server receives the request and returns a result to the server 120, and whether the interface is normal can be verified by comparing whether the returned result is consistent with an expected result.
As an example, in the scenario of order service, the test case may be written based on each flow of the order service, for example, an interface for submitting an order page and an interface for paying a page may be provided in the order service, and for the interface for submitting the order page, a corresponding test case may be written to test whether the interface is normal. For the interface of the payment page, a corresponding test case can be written for testing whether the interface is normal. In the context of order services, multiple interfaces of the service may be tested by multiple test cases.
When the interface test is performed, a plurality of test cases can be written for testing based on the test requirement of the interface. The test cases may include a forward case and a reverse case, where the forward case may refer to inputs supported by the system, and the reverse case may refer to inputs not supported by the system. For example, if an input can accept only the input numbers 2-9, then the forward use case may refer to 2,3,4,5,6,7,8,9, and by testing the forward use case, it may be detected whether the interface can achieve the expected feedback. Reverse use case may refer to other values, for example 0,1,0.1. By testing the reverse use case, it can be tested whether the interface can detect an abnormal input.
In step S20, it should be noted that, when testing a plurality of test cases, a certain test sequence may be tested according to the priority order. For example, the multiple test cases may be divided into a forward case and a reverse case, and the forward case may be detected first to detect a basic function of the interface during normal input. The reverse use case can then be detected to detect if the interface will generate a fault when an abnormal input is made. The priority of the test cases may be set such that the priority of the forward case is higher than the priority of the reverse case, and the test cases with higher priorities are prioritized.
It should be further noted that, when testing the forward use case, the forward use case may be sequenced according to the functionality of the interface, and tested in a certain test sequence. For example, in the forward case of an order service, an interface to query orders, an interface to submit order pages, and an interface to pay pages may be provided. Based on the importance of the interface function, the importance of the interface of the payment page may be set to be greater than the interface of the submit order page, which may be set to be greater than the interface of the query order. Therefore, when testing the forward use case, the interface of the payment page can be tested first, then the interface of the order submitting page can be tested, and finally the interface of the query order can be tested. Similarly, when testing reverse use cases, the reverse use cases can be sequenced according to the functionality of the interfaces, and the reverse use cases are tested in a certain test sequence.
It should be noted that the test case may execute the test task by the thread when performing the test. In one thread, multiple test cases may be executed in sequence. It should be noted that a thread may refer to an execution unit.
For step S30, it should be noted that, when the test case is executed, the page is still in the loading process after the interface request is initiated, and when the page element does not appear, the returned element information cannot be located, and the test case may generate error reporting information. In order to avoid unnecessary error reporting information, forced waiting can be invoked, and the forced test case waits for a preset time which is longer than the loading time of the page element, so that returned element information can be positioned after forced waiting, and unnecessary error reporting information is avoided. However, when forced waiting is performed, the whole thread cannot continue testing, resulting in a waste of time. In order to improve the execution efficiency of the test cases, when executing a certain test case, whether the test case triggers forced waiting or not can be judged, and when triggering forced waiting, other test cases are tested.
For step S40, when executing a certain test case, if the forced wait is triggered, the first thread currently tested is locked within a preset time, so as to avoid the thread from continuing to test the test case. Then, a second thread can be created to test all other test cases, so that unnecessary waiting time in the first thread is avoided, and the interface test efficiency is improved. If the forced waiting is not triggered in the test case testing process, the unfinished test case can be continuously tested. When the locking time of the first thread is over, for example, the page in the test case is loaded, the second thread can be locked, and the first thread is released and continues to be tested.
In step S50, it should be noted that, when the forced waiting is triggered, the first thread is locked for a preset time, and the second thread is created to test other test cases. And when the preset time is over, locking the second thread, and continuing to test the first thread. When the test case in the first thread triggers forced waiting again, the first thread can be locked again, and the second thread is released to continue testing. The test cases in the first thread can be executed completely, and other test cases in the second thread can be executed continuously.
It should be noted that if the forced wait is triggered when the test cases in the second thread are tested, the second thread may be locked again within the preset time, a third thread is established, and all other test cases are executed. Then, the threads are switched in the same manner as described above, and the test is alternated until all test cases have been tested.
For step S60, as shown in fig. 3, as an example, for the interface test task, four test cases a, B, C, D may be set, and the test sequence of a, B, C, D may be preset. And then starting the first thread S1 to test the four test cases A, B, C and D in sequence, locking the first thread S1 in a preset time when the test case A triggers forced waiting, starting the second thread S2 to test the three test cases B, C and D in sequence, and releasing and continuing to test the first thread S1 and locking the second thread S2 when the second thread S2 is executing the test case B, wherein the forced waiting of the first thread S1 is ended. If the test case A of the first thread S1 triggers the forced wait again, the first thread S1 is locked again within the preset time, so that the test case A in the first thread S1 is in the forced wait state, and the test case B in the second thread S2 is continuously tested. If the second thread S2 does not encounter the forced wait and executes to the test case C, and the forced wait of the first thread S1 ends again, the first thread S1 is released and tested, and the second thread S2 is locked. This alternates until the test is completed for the first thread S1. And then continuing to test the test case C in the second thread S2, when the test case C in the second thread S2 triggers forced waiting, starting the alternate test of the third thread S3, and testing by the same steps until all the test cases are tested.
It should be noted that the test sequence of all the test cases can be set based on the test requirements.
For step S70, it should be noted that after all test cases are tested, the test data of the test cases in each thread may be summarized to generate a test report, so that a developer may analyze the problems existing in the interface according to the test report.
It should be further explained that the test data may include a test result of each test case, test log information in each thread, and a thread number. The test log information may be an interface type, a request address, a request parameter, a response time, error reporting information, return information, and the like of the test case in each thread. From the test results, it can be known whether the result of the test case is an expected result. Specific test information of all test cases in each thread can be known through the log information, and a developer can analyze problems existing in the interface according to the log information.
In an exemplary embodiment, the process of obtaining the plurality of test cases of the preset interface test may include obtaining the plurality of test cases based on a target test task of the interface test.
It should be noted that, under different service scenarios, a corresponding target test task of the interface test may be set. For example, in the scenario of order service, an interface test task of submitting an order page may be tested, and an interface test task of paying a page or other test tasks may be tested, so that multiple test cases may be written correspondingly. Under different interface test requirements, different test cases can be correspondingly written, for example, when the basic functions of the interface under normal input need to be detected, a forward case can be written. If the interface generates error report when abnormal input needs to be detected, reverse use cases can be written.
In an exemplary embodiment, as shown in fig. 4, a first thread is created, in which a plurality of the test cases are sequentially tested, and the process of generating corresponding test data may include,
and S21, creating a first thread, and sequentially testing a plurality of test cases in the first thread.
Step S22, obtaining the test log information, the thread number and the test result of the first thread to generate test data of the thread.
When a thread is created to test a plurality of test cases, a thread S1 may be created, and the thread S1 may be set to test four test cases a, B, C, and D in sequence. When the thread is tested, log information, thread numbers and test results in the test process can be recorded, so that a subsequent developer can analyze problems occurring in the test case test of the thread according to the log information, the thread numbers and the test results.
It should be further described that the log information may be an interface type, a request address, a request parameter, a response time, error reporting information, return information, etc. of each test case in the thread, and may specifically reflect the test condition of the test case. The thread number may be a unique identifier representing the thread, which may 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 may be used to distinguish between the different threads.
In an exemplary embodiment, as shown in fig. 5, if the forced wait is triggered, the first thread currently tested is locked for a preset time, a second thread is created, and the process of sequentially testing all other test cases in the second thread may include,
and step S41, if the forced waiting is triggered, locking the first thread tested currently, creating a second thread, and sequentially testing all other test cases in the second thread.
Step S42, the creation process executes a timing task to record the locking time of the first thread which is currently locked.
It should be noted that, when the test case in the first thread triggers forced waiting, in order to avoid wasting unnecessary waiting time, the first thread currently tested may be locked, and the second thread may be created to test all other test cases. When the second thread is created, an initial process start timer can be created at the same time, and the locking time of the locked first thread is recorded. When the locking time is greater than or equal to the preset time, the forced waiting of the first thread is finished, the first thread can be released and tested continuously, and the second thread is locked.
It should be further explained that the process may be an executing program to perform timing tasks. The process and the thread are mutually independent when executing, the process is used for executing timing tasks, and the thread is used for executing test cases.
In an exemplary embodiment, as shown in fig. 6, a second thread is created, in which all other test cases are tested in turn, and the process of generating corresponding test data may include,
and S411, creating a second thread, and sequentially testing all other test cases in the second thread.
Step S412, obtaining the log information, the thread number and the test result of the second thread, so as to generate test data of the thread.
It should be noted that, when the test case in the first thread triggers forced waiting, in order to avoid wasting unnecessary waiting time, the first thread currently tested may be locked, and the second thread may be created to test all other test cases.
When the second thread tests, log information, thread numbers and test results of test cases in the test process can be recorded, so that a subsequent developer can analyze problems occurring in the test of the test cases in the second thread according to the log information, the thread numbers and the test results.
It should be further described that the log information may be an interface type, a request address, a request parameter, a response time, error reporting information, return information, etc. of each test case in the thread, and may specifically reflect the test condition of the test case. The thread number may be a unique identifier representing the thread, which may 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 may be used to distinguish between the different threads.
In an exemplary embodiment, as shown in fig. 7, when the preset time is over, the second thread currently tested is locked, and the process of continuing to test the first thread may include,
step S51, judging whether the locking time of the first thread which is currently locked is greater than the preset time of a timing task;
step S52, when the locking time of the first thread is greater than or equal to the preset time of the timing task, locking the second thread which is currently tested, and continuing to test the first thread;
and step S53, when the locking time of the first thread is smaller than the preset time of the timing task, continuing to lock the first thread.
It should be noted that, when the test case in the first thread triggers forced waiting, in order to avoid wasting unnecessary waiting time, the first thread currently tested may be locked, and the second thread may be created to test all other test cases. When the second thread is created, an initial process start timer can be created at the same time, and the locking time of the first thread is recorded. When the locking time is greater than or equal to the preset time of the timing task, the forced waiting of the first thread is finished, the first thread can be released and tested continuously, the second thread is locked, and when the first thread is tested, the second thread can be released and tested continuously. And when the locking time is smaller than the preset time of the timing task, continuing to lock the first thread which is currently locked. By using the alternative test mode, unnecessary waiting time can be avoided, and the test efficiency can be improved.
It should be mentioned that the preset time of the timing task is greater than or equal to the time of the forced waiting, so that when the locked thread is released, the forced waiting of the test case in the thread is finished, and the test can be continued.
It should be noted that, during the test, multiple threads may be created. For example, a first thread S1 tests an A test case, a second thread S2 tests a B test case and a C test case, and a third thread S3 tests a D test case. After all the test cases are tested, the test results of the test cases in each thread, the log information in each thread and the thread number can be summarized to generate a test report so that a developer can analyze the problems of the interface according to the test report.
The log information may be the interface type, request address, request parameter, response time, error information, return information, etc. of the test case in each thread. The specific test information of all the test cases in each thread can be known through the log information. From the test results, it can be known whether the result of the test case is an expected result. The thread corresponding to each test result can be distinguished through the thread number. The thread number, the log information and the test result of each thread correspond, and the test result of a developer through a certain test case can correspond to the corresponding thread number and the log information in the thread, so that the test result can be rapidly analyzed according to the log information.
Therefore, in the scheme, aiming at the interface test process, the interface test time can be effectively shortened, and the interface test efficiency is improved.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present invention.
In an embodiment, a forced wait based interface test device is provided, which corresponds to the forced wait based interface test method in the above embodiment one by one. As shown in fig. 8, the interface testing device based on forced waiting includes an acquisition module 101, a testing module 102, a judging module 103 and a summarizing module 104.
In an embodiment, the obtaining module 101 may be configured to obtain a plurality of test cases of a preset interface test. The obtaining module 101 may be specifically configured to create a plurality of test cases based on the target test task of the interface test.
In an embodiment, the test module 102 may be configured to create a first thread, and sequentially test a plurality of the test cases in the first thread to generate corresponding test data. The test module 102 may be specifically configured to create a first thread, test a plurality of the test cases in the first thread in sequence, and obtain test log information, a thread number and a test result of the first thread to generate test data of the thread.
In an embodiment, the test module 102 may be further configured to lock the first thread currently tested within a preset time if the forced wait is triggered, create a second thread, test all other test cases in the second thread in sequence, generate corresponding test data, and if the forced wait is not triggered, continue testing the test cases that are not complete in the first thread currently tested. The test module 102 may be further configured to lock the first thread currently tested if the forced wait is triggered, create a second thread, test all other test cases in the second thread in sequence, and create a process execution timing task to record the locking time of the first thread currently locked. The test module 102 may be further specifically configured to create a second thread, and sequentially test all other test cases in the second thread, and obtain log information, a thread number and a test result of the second thread to generate test data of the thread.
In an embodiment, the test module 102 may be further configured to lock the second thread currently tested and continue testing the first thread when the preset time is over. The test module 102 may be further specifically configured to determine whether the locking time of the first thread currently locked is greater than the preset time of the timing task, lock the second thread currently tested when the locking time of the first thread is greater than or equal to the preset time of the timing task, continue to test the first thread, and continue to lock the first thread when the locking time of the first thread is less than the preset time of the timing task. Further, the test module 102 may be further specifically configured to lock the second thread currently tested when the locking time of the first thread is greater than or equal to the preset time of the timing task, stop locking the first thread that was locked, and continue to test the first thread until the thread test is completed, and continue to test the second thread.
In an embodiment, the determining module 103 may be configured to repeatedly determine whether the currently tested thread triggers forced waiting until the test is completed for a plurality of test cases.
In one embodiment, the aggregation module 104 may be used to aggregate test data for all threads to generate test reports.
The invention provides an interface testing device based on forced waiting, which can effectively shorten the interface testing time and improve the interface testing efficiency aiming at the interface testing process.
For specific limitations of the forced wait based interface test apparatus, reference may be made to the above limitations of the forced wait based interface test method, and no further description is given here. The modules in the intelligent question-answering processing device can be realized in whole or in part by software, hardware and a combination thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server, and its internal structure may be as shown in fig. 9. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes non-volatile and/or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a 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 of the computer device is used for communicating with an external user terminal through network connection. The computer program, when executed by the processor, performs the functions or steps of the server side of the forced wait based interface test method.
In one embodiment, a computer device is provided, which may be a user terminal, and the internal structure thereof may be as shown in fig. 10. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. 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 of the computer device is for communicating with an external server via a network connection. The computer program, when executed by the processor, performs the functions or steps of the user side of the forced wait based interface test method.
In one embodiment, a computer device is provided comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the steps of when executing the computer program:
acquiring a plurality of test cases of a preset interface test;
creating a first thread, and sequentially testing a plurality of test cases in the first thread to generate corresponding test data;
judging whether the test case currently tested in the first thread triggers forced waiting or not;
if the forced waiting is triggered, locking the first thread currently tested in a preset time, creating a second thread, and sequentially testing all other test cases in the second thread to generate corresponding test data; if the forced waiting is not triggered, continuing to test the unfinished test cases in the first thread tested currently;
when the preset time is over, locking the second thread which is currently tested, and continuing to test the first thread;
repeatedly judging whether the currently tested test case triggers forced waiting or not until the test is completed on a plurality of test cases;
the test data for all threads is aggregated to generate a test report.
In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor, performs the steps of:
acquiring a plurality of test cases of a preset interface test;
creating a first thread, and sequentially testing a plurality of test cases in the first thread to generate corresponding test data;
judging whether the test case currently tested in the first thread triggers forced waiting or not;
if the forced waiting is triggered, locking the first thread currently tested in a preset time, creating a second thread, and sequentially testing all other test cases in the second thread to generate corresponding test data; if the forced waiting is not triggered, continuing to test the unfinished test cases in the first thread tested currently;
when the preset time is over, locking the second thread which is currently tested, and continuing to test the first thread;
repeatedly judging whether the currently tested test case triggers forced waiting or not until the test is completed on a plurality of test cases;
the test data for all threads is aggregated to generate a test report.
It should be noted that, the functions or steps that can be implemented by the computer readable storage medium or the computer device may correspond to the descriptions of the server side and the client side in the foregoing method embodiments, and are not described herein for avoiding repetition.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the various embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile 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 a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions.
The above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention, and are intended to be included in the scope of the present invention.
Claims (10)
1. The interface testing method based on forced waiting is characterized by comprising the following steps:
acquiring a plurality of test cases of a preset interface test;
creating a first thread, and sequentially testing a plurality of test cases in the first thread to generate corresponding test data;
judging whether the test case currently tested in the first thread triggers forced waiting or not;
if the forced waiting is triggered, locking the first thread currently tested in a preset time, creating a second thread, and sequentially testing all other test cases in the second thread to generate corresponding test data; if the forced waiting is not triggered, continuing to test the unfinished test cases in the first thread tested currently;
when the preset time is over, locking the second thread which is currently tested, and continuing to test the first thread;
repeatedly judging whether the currently tested test case triggers forced waiting or not until the test is completed on a plurality of test cases;
the test data for all threads is aggregated to generate a test report.
2. The forced waiting-based interface test method according to claim 1, wherein the step of acquiring a plurality of test cases of a preset interface test comprises:
and creating a plurality of test cases based on the target test task of the interface test.
3. The forced wait-based interface test method of claim 1, wherein the creating a first thread, testing a plurality of the test cases in the first thread in turn, and generating the corresponding test data comprises:
creating a first thread, and sequentially testing a plurality of test cases in the first thread;
and acquiring the test log information, the thread number and the test result of the first thread to generate test data of the thread.
4. The method for testing an interface based on forced waiting according to claim 1, wherein if the forced waiting is triggered, locking the first thread currently tested for a preset time, creating a second thread, and testing all other test cases in the second thread sequentially, the method comprises:
if the forced waiting is triggered, locking the first thread tested currently, creating a second thread, and sequentially testing all other test cases in the second thread;
the creation process performs a timing task to record the lock time of the first thread currently locked.
5. The method for testing an interface based on forced waiting according to claim 1, wherein the creating a second thread, testing all other test cases in the second thread in turn, and generating the corresponding test data includes:
creating a second thread, and sequentially testing all other test cases in the second thread;
and acquiring log information, a thread number and a test result of the second thread to generate test data of the thread.
6. The forced wait based interface test method of claim 1, wherein the step of locking the second thread currently tested and continuing to test the first thread when the preset time is over comprises:
judging whether the locking time of the first thread which is currently locked is longer than the preset time of a timing task or not;
when the locking time of the first thread is greater than or equal to the preset time of the timing task, locking the second thread which is currently tested, and continuing to test the first thread;
and continuously locking the first thread when the locking time of the first thread is smaller than the preset time of the timing task.
7. The method for testing an interface based on forced waiting according to claim 6, wherein when the locking time of the first thread is greater than or equal to the preset time of the timing task, locking the second thread currently tested, and continuing to test the first thread comprises:
when the locking time of the first thread is greater than or equal to the preset time of the timing task, locking the second thread which is currently tested;
stopping locking the first thread locked last, and continuing to test the first thread until the thread test is completed;
and continuing to test the second thread.
8. Interface testing arrangement based on forcing wait, characterized by comprising:
the acquisition module is used for acquiring a plurality of test cases of a preset interface test;
the testing module is used for creating a first thread, sequentially testing a plurality of test cases in the first thread, generating corresponding testing data, locking the first thread tested currently in preset time if forced waiting is triggered, creating a second thread, sequentially testing all other test cases in the second thread, generating corresponding testing data, continuously testing unfinished test cases in the first thread tested currently if forced waiting is not triggered, and locking the second thread tested currently when the preset time is over, and continuously testing the first thread;
the judging module is used for repeatedly judging whether the test case tested currently triggers forced waiting or not until the test is completed on a plurality of test cases;
and the summarizing module is used for summarizing the test data of all threads to generate a test report.
9. Computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the steps of the forced wait based interface test method according to any of claims 1 to 7 when the computer program is executed.
10. A computer readable storage medium storing a computer program, wherein the computer program when executed by a processor implements the steps of the forced wait based interface test method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310090588.3A CN116049004A (en) | 2023-02-09 | 2023-02-09 | Interface testing method, device, equipment and medium based on forced waiting |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310090588.3A CN116049004A (en) | 2023-02-09 | 2023-02-09 | Interface testing method, device, equipment and medium based on forced waiting |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116049004A true CN116049004A (en) | 2023-05-02 |
Family
ID=86127736
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310090588.3A Pending CN116049004A (en) | 2023-02-09 | 2023-02-09 | Interface testing method, device, equipment and medium based on forced waiting |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116049004A (en) |
-
2023
- 2023-02-09 CN CN202310090588.3A patent/CN116049004A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109460527B (en) | Product data configuration method, device, computer equipment and storage medium | |
| CN110928653B (en) | Cross-cluster task execution method and device, computer equipment and storage medium | |
| CN110716878B (en) | Automatic interface testing method, device and system | |
| CN110764998B (en) | Data comparison method, device, equipment and storage medium based on Django framework | |
| CN110647471B (en) | Interface test case generation method, electronic device and storage medium | |
| CN105302717A (en) | Detection method and apparatus for big data platform | |
| WO2019056720A1 (en) | Automated test case management method and apparatus, device, and storage medium | |
| CN110879781A (en) | Program debugging method and device, electronic equipment and computer readable storage medium | |
| CN116069571A (en) | Storage device performance automatic test method, device, equipment and storage medium | |
| CN112379913B (en) | Software optimization method, device, equipment and storage medium based on risk identification | |
| CN111341380B (en) | Test method and device for resetting SSD (solid State disk) controller and computer equipment | |
| CN116049004A (en) | Interface testing method, device, equipment and medium based on forced waiting | |
| CN116149901A (en) | Data verification test method and device and computer readable storage medium | |
| CN115757172A (en) | Test execution method and device, storage medium and computer equipment | |
| CN111427623B (en) | Program exit method, device, computer equipment and storage medium | |
| CN114756293A (en) | Service processing method, device, computer equipment and storage medium | |
| CN110969430B (en) | Suspicious user identification method, suspicious user identification device, computer equipment and storage medium | |
| CN112558982A (en) | Code detection method and device and computer equipment | |
| CN114253618B (en) | BIOS modification method and device based on different manufacturers, computer equipment and storage medium | |
| CN111242833B (en) | Management method and device of dyeing machine, electronic equipment and storage medium | |
| CN116820558A (en) | Application program development method, device, equipment, storage medium and program product | |
| CN117251361A (en) | Method, device, equipment and storage medium for testing system stability | |
| CN118012593A (en) | Function interrupt control method, function interrupt control device, computer equipment and storage medium | |
| CN118093362A (en) | Program testing method, device, equipment, storage medium and program product | |
| TW202307670A (en) | Device and method for automated generation of parameter testing requests |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |