SEKE 2012 Proceedings - Knowledge Systems Institute

Algorithm 2 MarkStatements function
Require:
block: program block to be processed;
Map new→old : 1-1 line-number mapping from new to old
statements for unchanged code segments;
CONFIDENCE: confidence category (i.e., LC, MC, or
HC).
Ensure:
Requirements W.R.T block will be properly labeled.
1: Stmts new ← block.Statements ∩ Map new→old .Keys;
2: if Stmts new ≠ ∅ then
3: Stmts old ← Map new→old .MapToValues(Stmts new );
4: if Stmts old .Confidence ≺ CONFIDENCE then
5: Mark all s ∈ Stmts with CONFIDENCE;
6: end if
7: else
8: for all block pre ∈ block.P reBlocks do
9: MarkStatements(block pre , Map new→old , MC);
10: end for
11: for all blcok succ ∈ block.SuccBlocks do
12: MarkStatements(block succ , Map new→old , MC);
13: end for
14: end if
ranging from δ.line nb to δ.line ne (Lines 13-15).
During the requirements labeling phase, all requirements
from Reqs state are initially assigned to the lowest confidence
category LC (Line 19). If test cases can cover those statements
in affected blocks Blocks old and Blocks new , they can be
aware of changes and further reveal potential faults with
high probability. In CATESR, for blocks in Blocks old collected
from Version i , their statements are also in Reqs state
as partial requirements, will be reassigned to the highest
confidence category HC (Lines 20-22). However, for blocks
in Blocks new collected from Version i+1 , their statements
may not exist in the older version Version i . To label these
requirements, we design a recursive function MarkStatements
(Algorithm 2) (Lines 23-25). When calling MarkStatements
for the first time, the statements in Version i will be marked
with the highest confidence category HC. If no such statements
exist, the algorithm will recursively check such statements in
predecessors and successors of current block, and mark them
with a lower confidence category MC.
2) Test Cases Classification Module (M 2 ): We use this
module to classify test cases into proper categories. Test
cases in the same category can at most cover the same level
of requirements’ confidence. After performing M 1 , all test
requirements are labeled by a confidence category (i.e., HC,
MC, orLC). Then, based on the total order relation given by
formula 1, for each test case tc in test suite TS, M 2 computes
the highest confidence of requirements which tc can cover,
denoted by Confidence, and put tc into one proper subset of
TS in accordance with Confidence. We use algorithm 3to
show the process of this module.
In Algorithm 3, we define three sets, TS HC , TS MC , and
TS LC to store test cases that can cover requirements with
Algorithm 3 Test Case Classification Algorithm
Require:
Requirements: labeled statement-level requirements;
TS: original test suite contains test cases to be classified;
Ensure:
TS is divided into 3 pieces, TS HC , TS MC , and TS LC ,
in which test cases can only get the highest confidence
HC, MC, and LC respectively.
1: TS HC ,TS MC ,TS LC ←∅;
2: for all tc in TS do
3: tc.Confidence ←LC;
4: for all req in Requirements do
5: if tc.Cover(req) &&
tc.Confidence ≺ req.Confidence then
6: tc.Confidence ← req.Confidence;
7: end if
8: end for
9: if tc.Confidence = HC then
10: TS HC .Add(tc);
11: else if tc.Confidence = MC then
12: TS MC .Add(tc);
13: else if tc.Confidence = LC then
14: TS LC .Add(tc);
15: end if
16: end for
confidence HC, MC, and LC at most respectively. Initially,
we set these result sets empty (Line 1). Then, for each test
case tc, wecompute the highest confidence of requirements
tc can cover (i.e., Confidence)(Lines 3-8). Finally, we add
tc to TS HC , TS MC ,orTS LC according to tc.Confidence
(Lines 9-15). After classification, each test case can be in only
one of TS’s subsets (i.e., TS HC , TS MC ,orTS LC ).
3) Test Suite Reduction Module (M 3 ): We use M 3 to
generate the final reduced test suite. After classification by
M 2 , original test suite TS is divided into three sub test suites
TS HC , TS MC , and TS LC . Then we can reduce these three
sub test suites by using a classical test suite reduction approach
HGS [7]. Three reduced test suite with each confidence category
HC, MC, and LC are respectively denoted by RT S HC ,
RT S MC , and RT S LC . Finally, we propose a strategy named
Partial-CATESR to generate the final reduced test suite.
Meanwhile to illustrate the effectiveness of Partial-CATESR,
we also propose another strategy named Full-CATESR for
comparison.
Partial-CATESR is motivated by research work of Gu et al.
[5]. They conjectured that not all test requirements need to be
covered during regression testing. Their empirical results show
that properly not covering irrelevant test requirements could
not only reduce the size of test suite, but also keep the FDA.
Similarly, our Partial-CATESR strategy pays more attention
to the test cases covering the most related requirements (i.e.,
TS HC ) and ensure the same requirement coverage of TS HC .
Based on the former analysis, reduced test suite RT S HC
has the highest confidence to cover the code changes after
modification, RT S MC the second, and RT S LC the lowest.
220