546 lines
25 KiB
HTML
546 lines
25 KiB
HTML
<!DOCTYPE html>
|
|
<html><head>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
|
<link href="sqlite.css" rel="stylesheet">
|
|
<title>TH3</title>
|
|
<!-- path= -->
|
|
</head>
|
|
<body>
|
|
<div class=nosearch>
|
|
<a href="index.html">
|
|
<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0">
|
|
</a>
|
|
<div><!-- IE hack to prevent disappearing logo --></div>
|
|
<div class="tagline desktoponly">
|
|
Small. Fast. Reliable.<br>Choose any three.
|
|
</div>
|
|
<div class="menu mainmenu">
|
|
<ul>
|
|
<li><a href="index.html">Home</a>
|
|
<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
|
|
<li class='wideonly'><a href='about.html'>About</a>
|
|
<li class='desktoponly'><a href="docs.html">Documentation</a>
|
|
<li class='desktoponly'><a href="download.html">Download</a>
|
|
<li class='wideonly'><a href='copyright.html'>License</a>
|
|
<li class='desktoponly'><a href="support.html">Support</a>
|
|
<li class='desktoponly'><a href="prosupport.html">Purchase</a>
|
|
<li class='search' id='search_menubutton'>
|
|
<a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
|
|
</ul>
|
|
</div>
|
|
<div class="menu submenu" id="submenu">
|
|
<ul>
|
|
<li><a href='about.html'>About</a>
|
|
<li><a href='docs.html'>Documentation</a>
|
|
<li><a href='download.html'>Download</a>
|
|
<li><a href='support.html'>Support</a>
|
|
<li><a href='prosupport.html'>Purchase</a>
|
|
</ul>
|
|
</div>
|
|
<div class="searchmenu" id="searchmenu">
|
|
<form method="GET" action="search">
|
|
<select name="s" id="searchtype">
|
|
<option value="d">Search Documentation</option>
|
|
<option value="c">Search Changelog</option>
|
|
</select>
|
|
<input type="text" name="q" id="searchbox" value="">
|
|
<input type="submit" value="Go">
|
|
</form>
|
|
</div>
|
|
</div>
|
|
<script>
|
|
function toggle_div(nm) {
|
|
var w = document.getElementById(nm);
|
|
if( w.style.display=="block" ){
|
|
w.style.display = "none";
|
|
}else{
|
|
w.style.display = "block";
|
|
}
|
|
}
|
|
function toggle_search() {
|
|
var w = document.getElementById("searchmenu");
|
|
if( w.style.display=="block" ){
|
|
w.style.display = "none";
|
|
} else {
|
|
w.style.display = "block";
|
|
setTimeout(function(){
|
|
document.getElementById("searchbox").focus()
|
|
}, 30);
|
|
}
|
|
}
|
|
function div_off(nm){document.getElementById(nm).style.display="none";}
|
|
window.onbeforeunload = function(e){div_off("submenu");}
|
|
/* Disable the Search feature if we are not operating from CGI, since */
|
|
/* Search is accomplished using CGI and will not work without it. */
|
|
if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
|
|
document.getElementById("search_menubutton").style.display = "none";
|
|
}
|
|
/* Used by the Hide/Show button beside syntax diagrams, to toggle the */
|
|
function hideorshow(btn,obj){
|
|
var x = document.getElementById(obj);
|
|
var b = document.getElementById(btn);
|
|
if( x.style.display!='none' ){
|
|
x.style.display = 'none';
|
|
b.innerHTML='show';
|
|
}else{
|
|
x.style.display = '';
|
|
b.innerHTML='hide';
|
|
}
|
|
return false;
|
|
}
|
|
</script>
|
|
</div>
|
|
<div class=fancy>
|
|
<div class=nosearch>
|
|
<div class="fancy_title">
|
|
TH3
|
|
</div>
|
|
<div class="fancy_toc">
|
|
<a onclick="toggle_toc()">
|
|
<span class="fancy_toc_mark" id="toc_mk">►</span>
|
|
Table Of Contents
|
|
</a>
|
|
<div id="toc_sub"><div class="fancy-toc1"><a href="#overview">1. Overview</a></div>
|
|
<div class="fancy-toc2"><a href="#history">1.1. History</a></div>
|
|
<div class="fancy-toc1"><a href="#operation">2. Operation</a></div>
|
|
<div class="fancy-toc1"><a href="#generating_a_test_program">3. Generating A Test Program</a></div>
|
|
<div class="fancy-toc2"><a href="#test_automation_scripts">3.1. Test Automation Scripts</a></div>
|
|
<div class="fancy-toc1"><a href="#test_coverage">4. Test Coverage</a></div>
|
|
<div class="fancy-toc1"><a href="#mutation_testing">5. Mutation Testing</a></div>
|
|
<div class="fancy-toc1"><a href="#th3_license">6. TH3 License</a></div>
|
|
</div>
|
|
</div>
|
|
<script>
|
|
function toggle_toc(){
|
|
var sub = document.getElementById("toc_sub")
|
|
var mk = document.getElementById("toc_mk")
|
|
if( sub.style.display!="block" ){
|
|
sub.style.display = "block";
|
|
mk.innerHTML = "▼";
|
|
} else {
|
|
sub.style.display = "none";
|
|
mk.innerHTML = "►";
|
|
}
|
|
}
|
|
</script>
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<h1 id="overview"><span>1. </span>Overview</h1>
|
|
|
|
<p>SQLite Test Harness #3 (hereafter "TH3") is one of
|
|
<a href="testing.html#harnesses">three test harnesses</a> used for testing SQLite.
|
|
TH3 meets the following objectives:</p>
|
|
|
|
<ul>
|
|
<li><p> TH3 is able to run on embedded platforms that lack the support
|
|
infrastructure of workstations.</p></li>
|
|
|
|
<li><p> TH3 tests SQLite in an as-deployed configuration using only
|
|
published and documented interfaces.
|
|
In other words, TH3 tests the compiled object code, not
|
|
the source code, thus verifying that no problems were introduced
|
|
by compiler bugs. "Test what you fly and fly what you test."</p></li>
|
|
|
|
<li><p> TH3 checks SQLite's response to out-of-memory errors, disk I/O
|
|
errors, and power loss during transaction commit. </p></li>
|
|
|
|
<li><p> TH3 exercises SQLite in a variety of run-time configurations
|
|
(UTF8 vs UTF16, different pages sizes, varying journal modes, etc.)
|
|
</p></li>
|
|
|
|
<li><p> TH3 achieves 100% branch test coverage (and 100%
|
|
<a href="https://en.wikipedia.org/wiki/Modified_condition/decision_coverage">MC/DC</a>)
|
|
over the SQLite core.
|
|
(Test coverage of extensions such as FTS and RTREE is less than 100%).
|
|
</p></li>
|
|
</ul>
|
|
|
|
<p>TH3 was originally written for validation testing only, but has
|
|
subsequently been used for development testing and debugging
|
|
as well, and has proven very helpful in those roles. A full-coverage
|
|
test takes less than five minutes on a workstation and hence
|
|
serves as a fast regression test during day-to-day maintenance
|
|
of the SQLite code base.</p>
|
|
|
|
<h2 id="history"><span>1.1. </span>History</h2>
|
|
|
|
<p>TH3 originated from an effort to test SQLite on
|
|
<a href="https://en.wikipedia.org/wiki/Symbian">SymbianOS</a>.
|
|
Prior to TH3, all SQLite tests were run using the
|
|
<a href="http://www.tcl.tk/">TCL</a> script language, but TCL would not (easily)
|
|
compile on SymbianOS which made testing difficult. The first attempt
|
|
to remedy this problem was the "TH1" (Test Harness #1) scripting
|
|
language - a reimplementation of parts of the TCL language in a
|
|
more portable form that would compile and run on SymbianOS, and
|
|
that was sufficient to run the SQLite tests. TH1
|
|
did not survive as a standard testing tool for SQLite,
|
|
but it did find continued service as a
|
|
scripting language used to customize the
|
|
<a href="http://www.fossil-scm.org/">Fossil</a> version control system.
|
|
There was also a "Test Harness #2" which was an attempt to
|
|
create a simple scripting language using operator prefix notation
|
|
to drive tests. TH3 was the third attempt.
|
|
|
|
</p><p>At about that same time, some avionics manufacturers were
|
|
expressing interest in SQLite, which prompted the SQLite developers
|
|
to design TH3 to support the rigorous testing standards of
|
|
<a href="https://en.wikipedia.org/wiki/DO-178B">DO-178B</a>.
|
|
|
|
</p><p>The first code for TH3 was laid down on 2008-09-25.
|
|
An intense effort over the next 10 months resulted in TH3 achieving
|
|
100% MC/DC on 2009-07-25. The TH3 code continues to be improved and
|
|
expanded.
|
|
|
|
</p><p>As of 2018-05-19, the TH3 source tree consists
|
|
and well over 500,000 lines of source code in 1709 separate files.
|
|
|
|
</p><h1 id="operation"><span>2. </span>Operation</h1>
|
|
|
|
<p>TH3 is a test program generator. The output of TH3 is a program
|
|
implemented in C-code and intended to be
|
|
linked against the SQLite library under test. The generated test
|
|
program is compiled and run on the target platform in order to verify
|
|
correct operation of SQLite on that platform.</p>
|
|
|
|
<p>The inputs to TH3 are test modules written in C or SQL and
|
|
small configuration
|
|
files that determine how to initialize SQLite. The
|
|
TH3 package includes 1,444 test
|
|
modules and more than 47 configurations (as of 2018-05-19).
|
|
New modules and configurations
|
|
can be added to customize TH3 for specialized applications.
|
|
Each time TH3 is run, it reads
|
|
a subset of the available test modules and configuration files to generate
|
|
a custom C program that performs all of the specified tests under all
|
|
specified configurations. A complete test of SQLite normally involves running
|
|
TH3 multiple times to generate multiple test programs covering different
|
|
aspects of SQLite's operation, then linking all test programs against
|
|
a common SQLite library and running them separately on the target platform.
|
|
</p>
|
|
|
|
<p>There are no arbitrary limits in TH3. One could generate a
|
|
single test program that contained all test modules and all configuration files.
|
|
However, such a test program might be too large to deploy on embedded
|
|
platforms. (As of 2018-05-19, a full-up TH3 test is over 850,000 lines and
|
|
58MB of C code.) TH3 provides the ability to break the library of test
|
|
modules up into smaller, more easily digested pieces.</p>
|
|
|
|
<p>Each individual test module might contain dozens, hundreds, or thousands
|
|
of separate tests. The test modules can be written in C or as scripts of
|
|
SQL or a mixture of the two. About two-thirds of the existing test modules are
|
|
written in pure SQL with the remainder either in pure C or a combination
|
|
of C and SQL.
|
|
</p>
|
|
|
|
<p>Each test module file contains a header which describes the circumstances
|
|
under which the test is valid. For a particular configuration, only those
|
|
modules that are compatible with the configuration are run. </p>
|
|
|
|
<h1 id="generating_a_test_program"><span>3. </span>Generating A Test Program</h1>
|
|
|
|
<p>The TH3 program generator is a TCL script named "<tt>mkth3.tcl</tt>".
|
|
To generate a test program, one has merely to run this script and supply
|
|
the names of files containing test modules and configurations on the
|
|
command line. Test modules are files that use the "<tt>.test</tt>" suffix
|
|
and configurations are files that use the "<tt>.cfg</tt>" suffix. A
|
|
typical invocation of mkth3.tcl might look something like the following:</p>
|
|
|
|
<div class="codeblock"><pre>tclsh mkth3.tcl *.test *.cfg >testprog1.c
|
|
</pre></div>
|
|
|
|
<p>The output from the mkth3.tcl script is a C program that contains
|
|
everything needed to run the tests - everything that is except for
|
|
the SQLite library itself. The generated test program contains
|
|
implementations for all of the support interfaces used by the test
|
|
modules and it contains the <tt>main()</tt> routine that drives the
|
|
tests. To convert the test program into a working executable, simply
|
|
compile it against SQLite:</p>
|
|
|
|
<div class="codeblock"><pre>cc -o testprog1 testprog1.c sqlite3.c
|
|
</pre></div>
|
|
|
|
<p>The compilation step shown immediately above is merely representative.
|
|
In a working installation, one would normally want
|
|
to specify optimization parameters and compile-time switches on the
|
|
compiler command line.</p>
|
|
|
|
<p>For testing on embedded systems, the mkth3.tcl script and the compiler
|
|
steps shown above are performed on an ordinary workstation using
|
|
a cross-compiler, then the resulting test program is
|
|
transferred onto the device to be run.</p>
|
|
|
|
<p>Once the test program is generated, it is run with no arguments to
|
|
perform the tests. Progress information as well as error diagnostics
|
|
appear on standard output. (Alternative output arrangements can be made
|
|
using a compile-time option for embedded devices that lack a standard
|
|
output channel.) The program returns zero if there are no
|
|
errors and non-zero if any problems were detected.</p>
|
|
|
|
<p>Typical output from a single TH3 test program run looks like this:
|
|
|
|
</p><div class="codeblock"><pre>With SQLite 3.8.11 2015-05-15 04:13:15 56ef98a04765c34c1c2f3ed7a6f03a732f3b886e
|
|
-DSQLITE_COVERAGE_TEST
|
|
-DSQLITE_NO_SYNC
|
|
-DSQLITE_SYSTEM_MALLOC
|
|
-DSQLITE_THREADSAFE=1
|
|
Config-begin c1.
|
|
Begin c1.pager08
|
|
End c1.pager08
|
|
Begin c1.build33
|
|
End c1.build33
|
|
Begin c1.orderby01
|
|
End c1.orderby01
|
|
<i>... 15014 lines of output omitted ....</i>
|
|
Begin 64k.syscall01
|
|
End 64k.syscall01
|
|
Begin 64k.build01
|
|
End 64k.build01
|
|
Begin 64k.auth01
|
|
End 64k.auth01
|
|
Config-end 64k. TH3 memory used: 6373738
|
|
Config-begin wal1.
|
|
Begin wal1.wal37
|
|
End wal1.wal37
|
|
Config-end wal1. TH3 memory used: 100961
|
|
All 226 VDBE coverage points reached
|
|
th3: 0 errors out of 1442264 tests in 213.741 seconds. 64-bit little-endian
|
|
th3: SQLite 3.8.11 2015-05-15 04:13:15 56ef98a04765c34c1c2f3ed7a6f03a732f3b886e
|
|
</pre></div>
|
|
|
|
<p>The output begins with a report of the <a href="c3ref/c_source_id.html">SQLITE_SOURCE_ID</a>
|
|
(cross-checked again <a href="c3ref/libversion.html">sqlite3_sourceid()</a>) for the
|
|
SQLite under test and the compile-time options used as reported
|
|
by <a href="c3ref/compileoption_get.html">sqlite3_compileoption_get()</a>. The output concludes with a summary
|
|
of the test results and a repeat of the <a href="c3ref/c_source_id.html">SQLITE_SOURCE_ID</a>. If any
|
|
errors are detected, additional lines detail the problem. The error
|
|
reporting lines always begin with a single space character so that they
|
|
can be quickly extracted from large output files using:
|
|
|
|
</p><div class="codeblock"><pre>grep "^ "
|
|
</pre></div>
|
|
|
|
<p>The default output shows the beginning and end of each configuration
|
|
and test module combination. In the example above "c1" and "64k" are
|
|
configurations and "pager08", "build33", "orderby01", etc. are test modules.
|
|
Compile-time and run-time options are available to increase or decrease
|
|
the amount of output.
|
|
The output can be increased by showing each test case within each
|
|
test module. The output can be decreased
|
|
by degrees: omitting test modules starts and stops,
|
|
omitting configuration starts and stops, and finally by omitting all output.
|
|
|
|
</p><h2 id="test_automation_scripts"><span>3.1. </span>Test Automation Scripts</h2>
|
|
|
|
<p>TH3 comes with additional TCL scripts that help automate the testing
|
|
process on workstations. The "th3make" script automatically runs "mkth3.tcl"
|
|
and "gcc" and then runs the resulting test program and checks the results.
|
|
Arguments to th3make include all of the "*.test" test modules and
|
|
"*.cfg" configurations that are to be included in the test. Additional
|
|
options to th3make can cause the test program to be compiled using different
|
|
compilers (GCC, Clang, MSVC), to use different output verbosity levels, to
|
|
run the test program under valgrind, to check the output for coverage using
|
|
gcov, and so forth. The th3make script also accepts "*.rc" filenames as
|
|
arguments. These *.rc files are just collections of other arguments that
|
|
are commonly used together for a single purpose. For example, the "quick.rc"
|
|
file contains a set of eight arguments to th3make that run a fast (3-minute)
|
|
full-coverage test. This allows the operator to type "./th3make quick.rc" as
|
|
a short-cut to typing out all of the required command-line options. The
|
|
following are a few of the more than 40 available *.rc files:
|
|
|
|
</p><ul>
|
|
<li><b>alignment</b><i>N</i><b>.rc</b> -
|
|
These files contain -D options to the compiler that are used by
|
|
various notable downstreams.
|
|
</li><li><b>cov.rc</b> - Options for measuring test coverage
|
|
</li><li><b>extensions.rc</b> - Options to enable <a href="fts3.html#fts4">FTS4</a>, <a href="rtree.html">R-Trees</a>,
|
|
and <a href="fileformat2.html#stat4tab">STAT4</a>.
|
|
</li><li><b>fast.rc</b> - Run most tests, including those not needed for
|
|
coverage, skipping only soak tests, using delivery compiler options
|
|
(ex: -O3)
|
|
</li><li><b>memdebug.rc</b> - like test.rc but also enable
|
|
<a href="compile.html#memdebug">-DSQLITE_MEMDEBUG</a>.
|
|
</li><li><b>min.rc</b> - Run the minimum set of tests needed for 100% coverage.
|
|
</li><li><b>quick.rc</b> - Run all tests required for 100% coverage tests
|
|
using -Os and <a href="compile.html#debug">-DSQLITE_DEBUG</a>.
|
|
</li><li><b>test.rc</b> - Run the same tests as in fast.rc but without
|
|
compiler optimization and enabling options like
|
|
<a href="compile.html#debug">-DSQLITE_DEBUG</a> and
|
|
-DSQLITE_ENABLE_EXPENSIVE_ASSERT.
|
|
</li><li><b>test-ex.rc</b> - long-running soak tests.
|
|
</li></ul>
|
|
|
|
<p>The TH3 repository also includes the "multitest.tcl" script, another
|
|
TCL script used to automate TH3 testing on workstations. Multitest.tcl
|
|
automatically compiles SQLite, then
|
|
runs ./th3make repeatedly with a variety of alignments, and captures
|
|
the output in a succinct summary screen. A typical multitest.tcl run
|
|
generates output that looks like this:
|
|
|
|
</p><div class="codeblock"><pre>./multitest.tcl -q --jobs 3
|
|
start-time: 2018-05-19 03:17:12 UTC
|
|
file mkdir sqlite3bld
|
|
cd sqlite3bld
|
|
exec sh /ramdisk/sqlite/configure
|
|
file copy -force config.h ../config.h
|
|
exec make clean sqlite3.c
|
|
file rename sqlite3.c ../sqlite3.c
|
|
file rename sqlite3.h ../sqlite3.h
|
|
exec make clean sqlite3.c OPTS=-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT=1
|
|
file rename sqlite3.c ../sqlite3udl.c
|
|
exec make clean sqlite3.c OPTS=-DSQLITE_SMALL_STACK=1
|
|
file rename sqlite3.c ../sqlite3ss.c
|
|
cd ..
|
|
*******************************************************************************
|
|
t01: cov.rc.................................................... Ok (00:03:42)
|
|
t02: cov.rc ++STAT4 ++DESERIALIZE -D_HAVE_SQLITE_CONFIG_H...... Ok (00:04:45)
|
|
t03: vfs-cov.rc................................................ Ok (00:03:59)
|
|
t04: demo.rc................................................... Ok (00:00:05)
|
|
t07: test.rc ../th3private/*.test.............................. Ok (00:00:21)
|
|
t08: test.rc ../th3private/*.test ++STAT4...................... Ok (00:01:41)
|
|
t05: quick.rc.................................................. Ok (00:04:26)
|
|
t09: quick.rc ~TEST_REALLOC_STRESS -funsigned-char............. Ok (00:05:39)
|
|
t10: quick.rc ~THREADSAFE=0 -DLONGDOUBLE_TYPE=double........... Ok (00:03:24)
|
|
t06: quick.rc extensions.rc -D_HAVE_SQLITE_CONFIG_H............ Ok (00:09:03)
|
|
t11: quick.rc sqlite3ss.c ~MAX_ATTACHED=125.................... Ok (00:04:39)
|
|
t12: quick.rc ~BYTEORDER=0 ++RTREE............................. Ok (00:07:28)
|
|
t13: quick.rc ~DISABLE_INTRINSIC ++RTREE....................... Ok (00:07:31)
|
|
t16: quick.rc ~TRACE_SIZE_LIMIT=15 cov1/main16.test............ Ok (00:00:22)
|
|
t14: quick.rc ~DIRECT_OVERFLOW_READ -fsigned-char.............. Ok (00:04:35)
|
|
t15: quick.rc ~UNTESTABLE ~EXTRA_IFNULLROW..................... Ok (00:01:44)
|
|
t17: quick.rc ~MAX_MMAP_SIZE=0................................. Ok (00:04:46)
|
|
t18: quick.rc ++NULL_TRIM ++OFFSET_SQL_FUNC.................... Ok (00:04:47)
|
|
t19: quick.rc ++BATCH_ATOMIC_WRITE ++DESERIALIZE............... Ok (00:05:41)
|
|
t20: lean1.rc quick.rc......................................... Ok (00:03:09)
|
|
t22: test.rc alignment2.rc sqlite3udl.c........................ Ok (00:44:22)
|
|
t21: test.rc alignment1.rc..................................... Ok (01:02:32)
|
|
t23: memdebug1.rc extensions.rc................................ Ok (01:49:58)
|
|
t25: valgrind1.rc -O3 extensions.rc............................ Ok (00:56:08)
|
|
t24: memdebug2.rc extensions.rc................................ Ok (01:43:34)
|
|
t27: test-ex1.rc............................................... Ok (00:45:00)
|
|
t26: valgrind2.rc -O3 extensions.rc............................ Ok (01:02:52)
|
|
t29: test-ex3.rc............................................... Ok (00:31:48)
|
|
t28: test-ex2.rc............................................... Ok (01:12:03)
|
|
t30: test-ex4.rc............................................... Ok (01:09:47)
|
|
t32: test.rc alignment4.rc -m32 CC=clang....................... Ok (00:48:31)
|
|
t31: test.rc alignment3.rc sqlite3udl.c........................ Ok (01:22:29)
|
|
t34: test.rc alignment6.rc..................................... Ok (00:35:31)
|
|
t33: test.rc alignment5.rc extensions.rc....................... Ok (00:59:33)
|
|
t35: test.rc alignment7.rc..................................... Ok (00:44:10)
|
|
t40: fast.rc alignment2.rc sqlite3udl.c........................ Ok (00:15:46)
|
|
t39: fast.rc alignment1.rc extensions.rc -m32.................. Ok (00:33:19)
|
|
t36: test.rc ~MUTATION_TEST.................................... Ok (00:35:45)
|
|
t42: fast.rc alignment4.rc..................................... Ok (00:13:03)
|
|
t43: fast.rc alignment5.rc..................................... Ok (00:13:32)
|
|
t44: fast.rc alignment6.rc..................................... Ok (00:11:41)
|
|
t41: fast.rc alignment3.rc sqlite3udl.c........................ Ok (00:26:31)
|
|
t45: fast.rc alignment7.rc..................................... Ok (00:12:57)
|
|
t46: fast.rc -fsanitize=undefined.............................. Ok (00:38:18)
|
|
*******************************************************************************
|
|
0 failures on 44 th3makes and 198583082 tests in (07:16:01) 3 cores on bella
|
|
SQLite 3.24.0 2018-05-18 17:58:33 c6071ac99cfa4b6272ac4d739fc61a85acb544f6c1c2a
|
|
</pre></div>
|
|
|
|
<p>As can be seen above, a single run
|
|
of multitest.tcl invokes th3make dozens of times and takes between 12 and 24
|
|
CPU hours. The middle section of the output shows the arguments to each
|
|
individual th3make run and the result and elapse time for that th3make.
|
|
All build products and output for the separate th3make runs are
|
|
captures in subdirectories for post-test analysis.
|
|
The two-line summary at the bottom shows the total number of errors and tests
|
|
over all th3make runs and the total elapse time, together with the
|
|
<a href="c3ref/c_source_id.html">SQLITE_SOURCE_ID</a> information for the version of SQLite that was
|
|
tested. This summary information is recorded in the
|
|
<a href="https://www.sqlite.org/checklists">release
|
|
checklist</a> during final testing.
|
|
|
|
</p><p>Abbreviations are applied in the multitest.tcl output so that
|
|
each th3make invocation will fit on a single 80-column output line.
|
|
The initial "th3make" verb is omitted.
|
|
"~" is shorthand for "-DSQLITE_" and "++" is stands for
|
|
"-DSQLITE_ENABLE". Hence, multitest.tcl output line
|
|
|
|
</p><div class="codeblock"><pre>quick.rc ~DISABLE_INTRINSIC ++RTREE
|
|
</pre></div>
|
|
|
|
<p>Really means
|
|
|
|
</p><div class="codeblock"><pre>th3make quick.rc -DSQLITE_DISABLE_INTRINSIC -DSQLITE_ENABLE_RTREE
|
|
</pre></div>
|
|
|
|
<h1 id="test_coverage"><span>4. </span>Test Coverage</h1>
|
|
|
|
<p>Using one particular subset of the available TH3 test modules (the "cov1"
|
|
tests) SQLite obtained
|
|
<a href="testing.html#coverage">100% branch test coverage</a> and 100% <a href="testing.html#mcdc">MC/DC</a> as measured
|
|
by <a href="http://gcc.gnu.org/onlinedocs/gcc/Gcov.html">gcov</a>
|
|
on Linux x86 and x86_64 hardware. All releases of SQLite since
|
|
<a href="releaselog/3_6_17.html">version 3.6.17</a> (2009-08-10) have been tested to this standard.
|
|
The SQLite developers
|
|
are committed to maintaining 100% branch coverage and MC/DC for all
|
|
future releases of SQLite.</p>
|
|
|
|
<p>The cov1 test set used to obtain 100% branch test coverage are only a
|
|
subset of the tests currently implemented using TH3. New test modules are
|
|
added on a regular basis.</p>
|
|
|
|
<a name="muttest"></a>
|
|
|
|
<h1 id="mutation_testing"><span>5. </span>Mutation Testing</h1>
|
|
|
|
<p>The TH3 source tree contains a scripted name
|
|
"mutation-test.tcl" that automates the process of
|
|
<a href="testing.html#mutationtests">mutation testing</a>.
|
|
|
|
</p><p>The mutation-test.tcl script takes care of all of the details for
|
|
running a mutation test:
|
|
|
|
</p><ol>
|
|
<li> The script compiles the TH3 test harness into machine code ("th3.o") if
|
|
necessary.
|
|
</li><li> The script compiles the sqlite3.c source file into assembly language
|
|
("sqlite3.s") if necessary.
|
|
</li><li> The script loops through instructions in the assembly language file
|
|
to locate branch operations.
|
|
<ol type="a">
|
|
<li>The script makes a copy of the original sqlite3.s file.
|
|
</li><li>The copy is edited to change the branch instruction into either
|
|
a no-op or an unconditional jump.
|
|
</li><li>The copy of sqlite3.s is assembled into sqlite3.o then linked
|
|
again th3.o to generate the "th3" executable.
|
|
</li><li>The "th3" binary is run and the output checked for errors.
|
|
</li></ol>
|
|
</li><li> The script shows progress for each cycle of the previous step then
|
|
displays a summary of "survivors" at the end. A "survivor" is a
|
|
mutation that was not detected by TH3.
|
|
</li></ol>
|
|
|
|
<p>Mutation testing can be slow, since each test can take up to 5
|
|
minutes on a fast workstation, and there are two tests for each
|
|
branch instructions, and over 20,000 branch instructions. Efforts are
|
|
made to expedite operation. For example, TH3 is compiled in such a
|
|
way that it exits as soon as it finds the first error, and as many
|
|
of the mutations are easily detected, many cycles happen in only
|
|
a few seconds. Nevertheless, the mutation-test.tcl script includes
|
|
command-line options to limit the range of code lines tested so that
|
|
mutation testing only needs to be performed on blocks of code that
|
|
have recently changed.
|
|
|
|
</p><h1 id="th3_license"><span>6. </span>TH3 License</h1>
|
|
|
|
<p>SQLite itself is in the <a href="copyright.html">public domain</a> and
|
|
can be used for any purpose. But TH3 is proprietary and requires a license.
|
|
</p>
|
|
|
|
<p>Even though open-source users do not have direct access to TH3, all
|
|
users of SQLite benefit from TH3 indirectly since each version of SQLite is
|
|
validated running TH3 on multiple platforms (Linux, Windows, WinRT, Mac,
|
|
OpenBSD) prior to release. So anyone using an official release
|
|
of SQLite can deploy their application with the confidence of knowing that
|
|
it has been tested using TH3. They simply cannot rerun those tests
|
|
themselves without purchasing a TH3 license.</p>
|
|
|