Browse Prior Art Database

Choose the possible fail test cases based on execution history and change set

IP.com Disclosure Number: IPCOM000241082D
Publication Date: 2015-Mar-26
Document File: 4 page(s) / 87K

Publishing Venue

The IP.com Prior Art Database

Abstract

This disclosure introduce one idea to choosethe possilbe fail test cases based on execution history and change set. And then the Unit test framework run these choosed cases to check if there will be fail test cases to find the potential issue for code check in.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 56% of the total text.

Page 01 of 4

Choose the possible fail test cases based on execution history and change set

      As you know when devlopers are developing on product, they will choose one unit test framework like Junit to write thousands of test cases to do automation testing, with more features are developed, more and more test cases will be added into automation testing. So when they get one successful build, they need to run all test cases, maybe it will take more than one day, it will be not acceptable for build testing. To verify if the build is acceptable for QA team quickly, they can decrease the test cases with test scope when writing test case. For example when one feature is done, developer can add the fundamental test cases to check if basic function can work well or not. Maybe they can call these test cases "Smoke test", after this, QA can add more positive and negative test cases, they call that "Regression test". So the test cases number of "Smoke test" will be less than "Regression test". It will take less time to verify the build is ok or not.

     But this method has the limitation that is the test cases in each scope are fixed. Fixed test case maybe can't detect the potential issue with code change .If we can construct the test cases based on code change in the latest build, it will detect maximum potential issues with code change within the acceptable time. That's this invention can provide the capability.

     The present invention will detect potential issue with code change within acceptable time instead of running all regression test. If they have the test cases execution history data, like which files is changed, code lines change scope, the failed test suite and method .They can build the model with popular statistic/analytic tool. Then get the changes from source code version control tool like CVS. Then using the model to predict which test suite and methods will be impacted and fail . Then add these test case into running test cases to verify if latest build is ok or not. So that it can detect potential issue with code change within acceptable time. That's the advantage of this invention.

Now it assume that they have one product named "Calculator", the Java source code will have

com.xx.Plus.java com.xx.Minus.java com....