Patent Issued for Software testing in parallel threads with a record-locking database (USPTO 11860772): State Farm Mutual Automobile Insurance Company
2024 JAN 23 (NewsRx) -- By a
Patent number 11860772 is assigned to
The following quote was obtained by the news editors from the background information supplied by the inventors: “During development of a software application, software developers can prepare tests to verify that the software application operates as expected. Such tests may be associated with unit testing that tests the functionality of a relatively small piece of code, and/or integration testing that tests how multiple pieces of code interact. Because individual tests may be designed to test one or more relatively small aspects of the overall software application, software developers may create numerous tests associated with the entire software application.
“Some tests associated with the software application may build on one another. For instance, a first test may create a record in a database, and a second test may be designed to further access or edit the database record created by the first test. In this situation, a developer may write code for the second test under the assumption that the first test will already have executed and created the record in the database by the time the second test executes. Accordingly, in this situation, the second test may be dependent on data created by the first test.
“In some situations, when a new version of the software application is tested, it can take a relatively long period of time to execute all of the tests and verify that the new version of the software application successfully passes all of the tests. For instance, tests can be written to build on each other in a sequential order as discussed above, and running a large set of tests in a sequence can take a relatively long period of time. As a non-limiting example, tests for a software application may be written in a set of 7000 class files that each include numerous functions, and it may take up to two hours to sequentially execute all of the tests in the 7000 class files.
“The time it takes to sequentially execute a large set of tests can pose challenges and introduce delays during software development, particularly in situations in which multiple developers are working on the same software application. As an example, a team of software developers may generate sixty new builds of the software application in a single day. If each build is tested using a set of 7000 class files that takes up to 120 minutes of server time to execute, the testing may take up to 7200 minutes of server time in a single day.
“As another example, two developers may check out code from a main code branch and independently make changes to the code for the software application. If the first developer submits updated code for testing, it may take two hours to run a full set of test cases on the first developer’s updated code. However, by the time the testing verifies that the first developer’s changes have passed the full set of test cases and can be incorporated back into the main code branch, the second developer may separately have submitted different code changes for testing. The code changes made by the second developer may be incompatible with the changes made by the first developer. Accordingly, even if the second developer’s changes also independently pass the full set of test cases, it may not be possible to incorporate those changes back into the main code branch due to incompatible changes already made by the first developer. If testing of the first developer’s code changes had been performed more quickly, the second developer could have been made aware of the first developer’s changes and accounted for them before the second developer submitted additional code changes for testing.
“Accordingly, it can be desirable to run a full set of tests on updated code for a software application more quickly than described above. One possibility for speeding up the testing process is to run different tests in parallel at the same time. For example, rather than running tests within a full set of 7000 class files in sequence, the tests can be divided into smaller sets that can be run simultaneously in two or more parallel threads. Although executing the full set of tests in sequence may take up to two hours, running different subsets of the tests simultaneously in parallel threads may allow the full set of tests to complete in 30 minutes or less. Developers can thus be notified whether their code changes pass the full set of tests more quickly, and allow code changes that have passed the full set of tests to be merged into a main code branch more quickly. In addition to executing a full set of tests more quickly for a single new build of a software application, running tests in parallel threads can also reduce overall usage of server time when multiple new builds of the software application are tested. For instance, if testing each build of a software application takes up to 120 minutes when tests are executed sequentially in a single thread, it can take up to 7200 minutes of server time to test sixty different builds in a day. If running the tests in parallel reduces the testing time for each build down to 30 minutes as discussed above, testing sixty builds in a day may instead take only 1800 minutes of server time. However, although executing tests in parallel can speed up testing of a software application, in some cases the parallelization itself can cause errors and/or failed tests during testing.
“For example, as discussed above, tests may be written under the assumption that the tests will build on one another in a sequential order. Code changes may pass such tests if the tests are indeed executed sequentially in the originally-intended order. However, the same code changes may not pass the same tests if the tests are executed out of order, for instance because related or dependent tests are executed out of order in different parallel threads.
“As an example, multiple tests may attempt to access the same table of a database. The database may be configured to at least briefly lock the table when the table is accessed by a code element, such that the database table cannot be changed by other code elements while the table is locked. If a set of tests are run sequentially in an intended order, a first test may have finished accessing a database table, and the table can thus be unlocked, by the time a second test later attempts to access the database table. The second test may succeed in this scenario due to the unlocked database table. However, if the tests are instead run in parallel as described above, there is a chance that different tests, executing simultaneously in different parallel threads, may attempt to access the same database table at essentially the same time. This can cause database conflicts, table locking errors, and/or failure of one or more of the tests. For instance, if a database table is locked due to a first test accessing the database table, the table may still be locked if a second test, executing in parallel with the first test, also attempts to access the database table. The database table locking can thus cause the second test to fail, even though the second test may have succeeded if it had been executed at a different time when the database table was not locked due to another test executing in parallel.
“The example systems and methods described herein may be directed toward mitigating or overcoming one or more of the deficiencies described above.”
In addition to the background information obtained for this patent, NewsRx journalists also obtained the inventors’ summary information for this patent: “Described herein are systems and methods for testing a software application using a set of test cases distributed among parallel threads, in association with a record-locking database. To avoid database conflicts that may occur when different test cases in different parallel threads attempt to access the same database simultaneously, testing of the software application can be performed in association with a record-locking database that locks database records individually instead of, for example, locking entire database tables. Locking individual database records, instead of entire database tables or other larger database elements, can reduce and/or eliminate the chances that a test case in one parallel thread will be unable to access a record in the database because another test case in another parallel thread is simultaneously accessing the same database table or larger database element.
“According to a first aspect, a computer-implemented method can include instantiating, by one or more processors of a computing device, a record-locking database associated with a software application. The method can also include identifying, by the one or more processors, a plurality of test cases associated with the software application, and distributing, by the one or more processors, individual test cases of the plurality of test cases among a plurality of test sets. The different test sets of the plurality of test sets can be configured to execute simultaneously in different parallel threads on the computing device. The method can further include locking, by the one or more processors, a first record in the record-locking database based on an access attempt by a first test case executing via a first parallel thread. The method can also include granting, by the one or more processors, a second test case access to a second record in the record-locking database while the first record is locked, wherein the second test case executes, via a second parallel thread, substantially simultaneously with the first test case executing via the first parallel thread.
“According to a second aspect, a computing device can include one or more processors and memory storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations can include instantiating a record-locking database associated with a software application, identifying a plurality of test cases associated with the software application, and distributing individual test cases of the plurality of test cases among a plurality of test sets. The plurality of test sets can correspond to a plurality of parallel threads. The operations can further include simultaneously executing the plurality of test sets via the plurality of parallel threads. The record-locking database can permit different test cases of the plurality of test cases, executing via different parallel threads of plurality of parallel threads, to simultaneously access different records in the record-locking database.
“According to a third aspect, one or more non-transitory computer-readable media can store computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations. The operations can include instantiating a record-locking database associated with a software application, identifying a plurality of test cases associated with the software application, and distributing individual test cases of the plurality of test cases among a plurality of test sets. Different test sets of the plurality of test sets can be configured to execute simultaneously in different parallel threads. The operations can further include locking a first record in the record-locking database based on an access attempt by a first test case executing via a first parallel thread. The operations can also include granting a second test case access to a second record in the record-locking database while the first record is locked, wherein the second test case executes, via a second parallel thread, substantially simultaneously with the first test case executing via the first parallel thread.”
The claims supplied by the inventors are:
“1. A computer-implemented method, comprising: distributing a plurality of test cases, configured to test interactions between a software application and a database, among a plurality of test sets; executing at least a first test set and a second test set, of the plurality of test sets, in parallel; locking, based on a first access attempt by a first test case in the first test set, a first record in the database; and granting a second test case in the second test set, based on a second access attempt by the second test case, access to a second record in the database while the first record is locked.
“2. The computer-implemented method of claim 1, wherein: the plurality of test cases comprises a set of classes, individual classes, of the set of classes, comprise one or more methods, the one or more methods are functions written in a programming language, and the distributing is performed at one or more of: a class level associated with the set of classes, or a method level associated with the one or more methods.
“3. The computer-implemented method of claim 1, further comprising: executing a third test set, of the plurality of test sets, in parallel with the first test set and the second test set; detecting a third access attempt, by a third test case in the third test set, to access the first record while the first record is locked; and blocking the third access attempt by the third test case based on the first record being locked.
“4. The computer-implemented method of claim 3, further comprising: determining that the first record is unlocked following the first access attempt by the first test case; and retrying execution of the third test case based on determining that the first record is unlocked.
“5. The computer-implemented method of claim 1, wherein the database is instantiated based on loading or instantiation of the software application.
“6. The computer-implemented method of claim 1, wherein the plurality of test cases was created based on an expectation of individual test cases, of the plurality of test cases, being executed in a sequential execution order.
“7. The computer-implemented method of claim 1, further comprising: collecting test results associated with the plurality of test sets, based on execution of the plurality of test sets in parallel, and combining the test results into an aggregated test result report.
“8. The computer-implemented method of claim 1, wherein the distributing of the plurality of test cases among the plurality of test sets is based at least in part on predicting execution times of different test sets of the plurality of test sets.
“9. A computing device, comprising: one or more processors; memory storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: distributing individual test cases, of a plurality of test cases configured to test interactions between a software application and a database, among a plurality of test sets; simultaneously executing the plurality of test sets in parallel; and granting different test cases, in different test sets of the plurality of test sets, simultaneous access to different records in the database while the different test cases are executing in parallel.
“10. The computing device of claim 9, wherein: the plurality of test cases comprises a set of classes, individual classes, of the set of classes, comprise one or more methods, and the distributing is performed at one or more of: a class level associated with the set of classes, or a method level associated with the one or more methods.
“11. The computing device of claim 9, wherein the operations further comprise: loading the software application, and instantiating the database in response to loading the software application.
“12. The computing device of claim 9, wherein the operations further comprise: at a first time, blocking a first test case in a first test set from accessing a particular record in the database during access of the particular record by a second test case in a second test set; and at a second time after the second test case has finished accessing the particular record, granting the first test case access to the particular record.
“13. The computing device of claim 9, wherein the plurality of test cases was created based on an expectation of the individual test cases being executed in a sequential execution order.
“14. The computing device of claim 9, wherein the operations further comprise: collecting test results associated with the plurality of test sets, based on execution of the plurality of test sets in parallel; and combining the test results into an aggregated test result report.
“15. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations, comprising: distributing a plurality of test cases, configured to test interactions between a software application and a database, among a plurality of test sets; executing at least a first test set and a second test set, of the plurality of test sets, in parallel; locking, based on a first access attempt by a first test case in the first test set, a first record in the database; and granting a second test case in the second test set, based on a second access attempt by the second test case, access to a second record in the database while the first record is locked.
“16. The one or more non-transitory computer-readable media of claim 15, wherein: the plurality of test cases comprises a set of classes, individual classes, of the set of classes, comprise one or more methods, and the distributing is performed at one or more of: a class level associated with the set of classes, or a method level associated with the one or more methods.
“17. The one or more non-transitory computer-readable media of claim 15, wherein the operations further comprise: executing a third test set, of the plurality of test sets, in parallel with the first test set and the second test set; detecting a third access attempt, by a third test case in the third test set, to access the first record while the first record is locked; blocking the third access attempt by the third test case based on the first record being locked; determining that the first record is unlocked following the first access attempt by the first test case; and retrying execution of the third test case based on determining that the first record is unlocked.
“18. The one or more non-transitory computer-readable media of claim 15, wherein the plurality of test cases was created based on an expectation of individual test cases, of the plurality of test cases, being executed in a sequential execution order.
“19. The one or more non-transitory computer-readable media of claim 15, wherein the operations further comprise: collecting test results associated with the plurality of test sets, based on execution of the plurality of test sets in parallel, and combining the test results into an aggregated test result report.
“20. A system for software testing in parallel, the system comprising: means for distributing a plurality of test cases, configured to test interactions between a software application and a database, among a plurality of test sets, means for executing at least a first test set and a second test set, of the plurality of test sets, in parallel; means for locking, based on a first access attempt by a first test case in the first test set, a first record in the database; and means for granting a second test case in the second test set, based on a second access attempt by the second test case, access to a second record in the database while the first record is locked.”
URL and more information on this patent, see: Chauhan, Shaktiraj. Software testing in parallel threads with a record-locking database.
(Our reports deliver fact-based news of research and discoveries from around the world.)
Patent Application Titled “Systems And Methods For Modeling Telematics, Positioning, And Environmental Data” Published Online (USPTO 20240005411): Patent Application
Patent Issued for System and method for indicating whether a vehicle crash has occurred (USPTO 11861715): State Farm Mutual Automobile Insurance Company
Advisor News
Annuity News
Health/Employee Benefits News
Life Insurance News