Download PPTX

Database State Generation
via
Dynamic Symbolic Execution for Coverage Criteria
Kai Pan, Xintao Wu
University of North Carolina at Charlotte
1
DBTest11
June 13, Athens, Greece
Tao Xie
North Carolina State University
We leverage DSE as a
supporting technique to
generate database states to
achieve high code coverage
(BVC and CACC in addition to
branch coverage).
2
Outline
 Introduction:
-- Dynamic Symbolic Execution(DSE)
-- Advanced structural coverage criteria(BVC and LC)
 Approach
 Evaluation
 Related work
 Conclusion and future work
3
Dynamic Symbolic Execution(DSE) -- Revisited
 DSE: An effective automatic test-input generation approach that
combines concrete execution with symbolic execution
 Details:
-- Starts with default or arbitrary inputs and executes the program
concretely
-- Performs symbolic execution to collect symbolic constraints on
the inputs simultaneously
-- Flips a branch condition and conjuncts it with constraints from
the prefix of the executed path
-- Sends the conjuncted conditions to a constraint solver to
generate new inputs for the uncovered paths
4
DSE in Testing Database Applications -- Revisited
 When DSE is applied on database applications, the
symbolic execution collects constraints over both the
program inputs and the symbolic database, by
symbolically tracking the concrete SQL queries executed
along the execution path
 Generates both program input values and corresponding
database records via a constraint solver
Related work:
M.Emmi, R.Majumdar, and K.Sen. Dynamic test input generation for database
applications. In ISSTA, 2007.
5
K. Taneja,Y. Zhang, and T. Xie. MODA: Automated Test Generation for Database
Applications via Mock Objects. In ASE 2010
Boundary Value Coverage
 Boundary Value Coverage(BVC): requires to execute
programs using values from both the input range and
boundary conditions. This is because program errors
tend to occur at extreme or boundary points.
 Example: for integers A and B in one expression, we
have:
6
Logical Coverage
 Logical Coverage (LC): involves instantiating clauses in a
logical expression (predicate) with concrete truth
values.
 Predicate/Clause/Combinatorial/Active Clause coverage
 Correlated Active Clause Coverage (CACC), value of a logical
expression is directly dependent on the value of the
clause that we want to test
 Formally, for each predicate p and each major clause ci ∈
p, choose minor clauses cj , j≠ i so that ci determines
p.(required that p(ci = true) ≠ p(ci = false).)
7
Enforcing CACC and BVC
 Example: in the example code (Line 20), for the
predicate pc4 = (bal>=250000||employed && married)
with the target evaluation result as true
 We choose rows 1 and 4 from the table to enforce CACC
8
Enforcing CACC and BVC(cont’d)
 To enforce BVC on the clause “(bal>=250000)”, we get
{bal=250000, bal>250000, bal=maximum}
 For the entire predicate, we get the following six instantiations:
{bal=250000, employed=true, married=false},
{bal>250000, employed=true, married=false},
{bal=maximum, employed=true, married=false},
{bal=250000-1, employed=true, married=true},
{bal<250000-1, employed=true, married=true},
{bal=minimum, employed=true, married=true}.
9
Enforcing CACC and BVC(cont’d)
 In general, given a predicate and a boolean evaluation as
input, we generate instantiations using:
CACC
BVC
10
Our work
 Our approach leverages DSE to track how the inputs to
the program under test are transformed before
appearing in the executed queries and how the
constraints on query results affect the later program
execution.
 We use Pex, a state-of-the-art DSE engine for .NET to
illustrate our idea
 The approach can be extended to other DSE engines for
other programming languages
11
Pex APIs
 APIs provided by Pex help users fetch symbolic
expressions:
-- PexSymbolicValue.ToString() to get the target query string at
each query execution point
-- PexSymbolicValue.GetRelevantInputNames<Type>() to detect the data
dependency between the execution point and program
input parameters.
-- PexSymbolicValue.GetPathConditionString() to retrieve the path
condition at the execution point
12
Illustrative example
 Our focus: how to generate
sufficient database states to
satisfy BVC and CACC .
Challenges:
1. Input parameters involved in
both embedded queries and
branch conditions(e.g. int
inputAge)
2. Branch conditions involve
variables that are related with
returned database attribute
13 values(e.g. Line 20)
Illustrative example(cont’d)
 We use path P (where branch
conditions in Lines 03, 08, 16, and
20 are true) and program inputs
(type = 0, inputAge = 30) as an
example
 We get path condition PC = pc1 ∧
pc2∧ pc3 ∧ pc4, where pc1 = (type
== 0), pc2 = (inputAge > 25), pc3
= (results.Read() == true), and pc4
= ((bal >= 250000 || employed &&
married) == true).
14
type=0,inputAge=30
Illustrative example(cont’d)
 We get the concrete executed query string
Q:
SELECT C.SSN, C.jobStatus, C.marriage, M.balance
FROM customer C, mortgage M
WHERE M.year=15 AND C.SSN=M.SSN
And C.age=40
and the symbolic query string Qsym:
SELECT C.SSN, C.jobStatus, C.marriage, M.balance
FROM customer C, mortgage M
WHERE M.year=:years AND C.SSN=M.SSN
AND C.age=:fAge
15
Illustrative example(cont’d)
 For Q and Qsym, the WHERE
clause contains host variables
that appear directly in branch
conditions or are dependent
on host variables in branch
conditions (Line 08)
 Hence, enforcing BVC on this
branch condition (Line 08)
incurs constraints on the
generated data.
16
Illustrative example(cont’d)
 Branch condition (Line 20)
contains three host variables (bal,
employed, and married) that
retrieve values from three
database attributes (M.balance,
C.jobStatus, C.marriage) in the
returned result set
 Enforcing CACC and BVC on the
branch condition(Line 20) incurs
new constraints on the generated
data
17
Embedded query(in a DPNF form):
Part1: Deriving constraints by
examining the WHERE clause
and the branch conditions
before the query’s execution.
Part2:Deriving constraints by
examining the SELECT clause
and the branch conditions
after the query’s execution.
18
Deriving Constraints from Embedded Query
 Constraints from executed queries:
19
Deriving Constraints from Embedded Query(cont’d)
 Set CQ = (A11 AND …AND A1n) OR … OR (Am1 AND
…AND Amn) --- the WHERE clause of Qsym
 For each Aij, we check whether it contains host variables.
 For each contained host variable,
 if it is related with any branch condition, we add it to VQ
and replace it with symbolic string expressed by variables
in the related branch conditions.
 Otherwise, we replace the variable with its concrete value
contained in the concrete query.
20
Deriving Constraints from Embedded Query(cont’d)
 Using our example code:
-- CQ = {M.year=:years AND C.SSN= M.SSN AND C.age=:fAge}.
-- For M.year=:years, we replace “years” with the value “15”.
-- For C.age=:fAge, we replace “fAge” with “inputAge + 10”.
-- For C.SSN= M.SSN, we leave it unchanged.
-- CQ = {M.year=15 AND C.SSN= M.SSN AND C.age=:inputAge + 10}.
21
Deriving Constraints from Embedded Query(cont’d)
 Next, we check whether the branch condition pc along
the execution path contains host variables related with
the WHERE clause.
 If yes, we enforce it with both CACC and BVC and get
instantiations Ipc
 We refine CQ as CQ = CQ × Ipc.
22
Deriving Constraints from Embedded Query(cont’d)
 Using our example code:
-- Enforcing BVC on inputAge> 25, we have instantiations
{inputAge=25+1, inputAge>25+1, inputAge=maximum}.
-- CQ is then updated as
{M.year=15 AND C.SSN= M.SSN AND C.age=:inputAge+10 AND inputAge=25+1},
{M.year=15 AND C.SSN= M.SSN AND C.age=:inputAge+10 AND inputAge>25+1},
{M.year=15 AND C.SSN= M.SSN AND C.age=:inputAge+10 AND
inputAge=maximum}.
23
Deriving Constraints related with Query Result Set
 For branch conditions after the SQL’s execution point,
we check whether they contain host variables that are
dependent on database attributes in the SELECT clause,
and then enforce CACC and BVC.
24
Deriving Constraints related with Query Result Set(cont’d)
 Using our example code: pc4 = ((bal >= 250000 ||
employed && married) == true) , we have CR
{bal=250000, employed=true, married=false},
{bal>250000, employed=true, married=false},
{bal=maximum, employed=true, married=false},
{bal=250000-1, employed=true, married=true},
{bal<250000-1, employed=true, married=true},
{bal=minimum, employed=true, married=true}.
 We then replace host variables (e.g., bal) with database
attributes (e.g., M.balance).
25
Combining Constraints
 Finally, the set C = CQ×CR contains constraints on the
generated database state to enforce CACC and BVC on
the source code under test.
 We send C together with the schema level constraints CS
to a constraint solver (Z3) to conduct the data
instantiation
26
Evaluation
 We conduct evaluations on two open source database
applications.
 RiskIt: 4.3K non-commented lines of code, a database
containing13 tables, 57 attributes, and more than 1.2
million records
 UnixUsage: 2.8K non-commented lines of code, a database
containing 8 tables, 31 attributes, and more than 0.25
million records
 We choose methods that have boundary values and/or
logical expressions in branch conditions from the
applications.
27
Evaluation(cont’d)
 To measure CACC and BVC, we apply a tool [Pandita et
al. ICSM10] that transforms the problem of achieving
CACC and BVC to the problem of achieving block
coverage by introducing new blocks through code
instrumentation.
 We use PexGoal.Reached() to identify whether each
introduced block is covered. For example, the statement
if (inputAge > 25) {...} in Line 08 becomes
28
Evaluation(cont’d)
 We use the value of (n2 - n1)/n to capture the increase gained by
Pex assisted by our approach in achieving CACC and BVC.
 n denotes the total number of PexGoal.Reached() statements
introduced in each method.
 n1 denotes the number of covered PexGoal.Reached() statements
when running Pex (in addition to our program input generation
tool) without applying our algorithm to generate new records.
 n2 denotes the number of covered PexGoal.Reached() statements
when running Pex with the assistance of our algorithm.
29
Evaluation(cont’d)
 Evaluation results: our approach assists Pex to reach the
full CACC and BVC coverage (a 21.21% increase on
average for RiskIt and a 46.43% increase for UnixUsage).
30
Related work
 Coverage criteria:
-- BVC and LC [Ammann et al. ISSRE 2003, Kosmatov et al. ISSRE
2004]
-- test generation to reach high BVC and LC [Pandita et al.
ICSM 2010]
 DB application testing:
-- generating database states from scratch[Chays and Shahid
DBTest 2008, Emmi et al. ISSTA 2007,Taneja et al. ASE 2010]
-- using existing database state[Li and Csallner DBTest 2010,
Pan et al. UNC-Chalotte TR-2011]
31
Related work (cont’d)
 SQLFpc (short for SQL Full Predicate Coverage)
 A coverage criterion focusing on an isolated SQL
statement, based on the Modified Condition/Decision
Coverage(MC/DC).
 Mutates a given SQL query statement into a set of queries
that satisfy MC/DC with the aim of detecting faults in the
SQL statement.
 [Tuya et al. 2010, Riva et al. AST 2010].
 Our work leaves the embedded SQL statement
unchanged. Instead, we generate database states with the
aim of detecting faults in source code.
32
Conclusion
 We developed a general approach to generating test
database states that can achieve BVC and CACC in
database application testing.
 We expect that testers can detect more faults that occur
in boundaries or involve complex logical expressions.
 We implemented our approach in Pex, a DSE tool for
.NET. Our evaluation demonstrated the feasibility of our
approach.
33
Future work
 We plan to investigate how to optimize the constraint
collection and data instantiation.
 We plan to study complex SQL queries (e.g.,
GROUPBY queries with aggregations) and extend our
technique to multiple queries.
34
Thank you! Questions?
Acknowledgment: This work was supported in part by U.S. National Science
Foundation under CCF-0915059 for Kai Pan and XintaoWu, and under CCF0915400 for Tao Xie.
35