Browse Prior Art Database

Architecture for On-Demand Testcase Selection System Disclosure Number: IPCOM000177877D
Original Publication Date: 2009-Jan-08
Included in the Prior Art Database: 2009-Jan-08
Document File: 1 page(s) / 26K

Publishing Venue



For a mature software product, there may be many testcases, either accumulated by previous version's FVT or APAR, or added by new line items. Unfortunately, to run through the full test suite may take days or sometimes, weeks. Often, this needs to done to ship a fix to customers or to integrate a fix into the software product. However, frequently most testcases are unrelated to the fix, and running these unrelated testcases increases the defect/APAR turnaround time. Although a specific bucket of testcases may be selected to run, unfortunately, this is a manual process that requires a certain knowledge of each bucket. Without that certain knowledge, either too many testcases may be selected or not all of the affected testcases may be selected. Thus, a testcase selection system that can effectively pick up the testcases that are directly related to the code change is needed.

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

Page 1 of 1

Architecture for On-Demand Testcase Selection System

For each testcase, the function name that code path will visit is tracked and stored. When the code for a particular function is changed, the tracking allows running just "affected" testcases, and not the full set/buckets.

Three phases:
1) testcase registration phase

This only needs to run once for each testcase (except those requiring re-registration, see #3 below).
a) create a database table (say, testcase table) with three columns for tracking the relationship of the testcase and the functions it visits.
testcase# - integer, e.g. 1, 2, 3...
function visited - varchar, e.g classA.ftn1; moduleA,ftn1...
candidate for testcase re-registration - YES|NO
b) build a debug version of the source such that during a testcase execution, a database table update will happen when a function is visited.

So, after testcase 3 is executed, the following testcase table is updated as follows: testcase# function visited candidate for testcase re -registration 1 classA.ftn1 NO
1 classA.ftn3 NO
1 classB.ftn2 NO
1 classC.ftn1 NO
2 classD.ftn1 NO
2 classE.ftn3 NO
2 classE.ftn2 NO
3 classA.ftn1 NO
3 classB.ftn2 NO
3 classC.ftn1 NO

2) testcase selection phase

This is initiated when the developer wants to test a fix. This can be implemented automatically as part of a check-in process.
a) developer identifies the function modified by the developer (or the check-in process automatically identifies the modified f...