![]() |
|
|||
WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233 |
Visa 4274 3200 2453 6495 |
SQLite Test Harness #3 (кратко "TH3") это один из
трех испытательных блоков,
используемых для тестирования SQLite. TH3 достигает следующих целей: TH3 в состоянии работать на встроенных
платформах, которые испытывают недостаток в инфраструктуре
поддержки рабочих станций. TH3 проверяет SQLite в развернутой конфигурации, используя только
изданные и зарегистрированные интерфейсы. Другими словами, TH3 проверяет
собранный объектный код, не исходный код, таким образом проверяя, что никакие
проблемы не были введены ошибками компилятора. TH3 проверяет ответ SQLITE на ошибки out-of-memory, дискового I/O и
потери мощности во время передачи транзакций. TH3 осуществляет SQLite во множестве конфигураций во время выполнения
(UTF8 против UTF16, различных размеров страниц, переменных режимов
журнала и т. д.). TH3 достигает 100% тестового покрытия отделения (и 100%
MC/DC) ядра SQLite. Тестовое покрытие расширений, таких как FTS и RTREE
составляет меньше, чем 100%. TH3 был первоначально написан только для проверки, но впоследствии
использовался для тестирования развития и отладки также, и оказался очень
полезным в тех ролях. Тест на полный охват занимает меньше, чем пять минут на
рабочей станции и следовательно служит быстрым регрессионным тестом во время
ежедневного обслуживания кодовой базы SQLite. TH3, порожден из усилия проверить SQLite на
SymbianOS.
До TH3 все тесты SQLite были запущены, используя язык
TCL, но TCL (легко) не соберется на
SymbianOS, что сделало тестирование трудным.
Первая попытка исправить эту проблему была "TH1" (Test Harness #1),
переопределение частей языка TCL в более портативной форме, которая будет
собираться и работать на SymbianOS, и это было достаточно, чтобы запустить
тесты SQLite. TH1 не прижился
как стандартный инструмент тестирования для SQLite, но это действительно
был хороший сервис, поскольку язык сценариев раньше настраивал систему
управления версиями Fossil.
Был также "Test Harness #2", который был попыткой создать простой язык
сценариев, используя префиксную нотацию оператора, чтобы стимулировать тесты.
TH3 был третьей попыткой. В приблизительно то же самое время некоторые авиационные производители
выражали интерес к SQLite, который побудил разработчиков SQLite к дизайну
TH3, чтобы поддерживать строгие стандарты тестирования
DO-178B. Первый код для TH3 был установлен 2008-09-25. Интенсивное усилие за
следующие 10 месяцев привело к TH3, достигающему 100% MC/DC 2009-07-25.
Код TH3 продолжает улучшаться и расширяться. С 2018-05-19 исходное дерево TH3 включает более 500000
строк кода в 1709 файлах. TH3 это генератор тестовой программы. Продукция TH3 это
программа, осуществленная в C-коде и предназначенная, чтобы быть связанной с
библиотекой SQLite при тесте. Произведенная тестовая программа собрана и
работает на целевой платформе, чтобы проверить правильную работу SQLite
на той платформе. Ввод TH3 это испытательные модули, написанные на C или SQL и
маленьких конфигурационных файлах, которые определяют, как инициализировать
SQLite. Пакет TH3 включает 1444 испытательных модуля и больше 47 конфигураций
(с 2018-05-19). Новые модули и конфигурации могут быть добавлены, чтобы
настроить TH3 для специализированных приложений. Каждый раз, когда TH3
работает, он читает подмножество доступных испытательных модулей и
конфигурационных файлов, чтобы произвести обычную
C-программу, которая выполняет все указанные тесты под всеми указанными
конфигурациями. Полный тест SQLite обычно включает управление TH3
многократно, чтобы произвести многочисленные тестовые программы, касающиеся
различных аспектов действия SQLITE, затем связывая все тестовые программы с
общей библиотекой SQLite и управляя ими отдельно на целевой платформе. В TH3 нет никаких произвольных пределов. Можно было произвести
единственную тестовую программу, которая содержала все испытательные модули и
все конфигурационные файлы. Однако, такая тестовая программа могла бы быть
слишком большой, чтобы развернуться на вложенных платформах. С 2018-05-19
полный тест TH3 это более 850000 строк и 58MB кода на C. TH3 обеспечивает
способность разбить библиотеку испытательных модулей на меньшие, более
легко обрабатываемые части. Каждый отдельный испытательный модуль мог бы содержать десятки, сотни или
тысячи отдельных тестов. Испытательные модули могут быть написаны на
C, как сценарии SQL или как смесь того и другого.
Приблизительно две трети существующих испытательных модулей написаны
на чистом SQL. Каждый испытательный файл модуля содержит заголовок, который описывает
обстоятельства, при которых тест действителен. Для особой конфигурации
управляют только теми модулями, которые совместимы с конфигурацией. Генератор программы TH3 это скрипт TCL под названием
"mkth3.tcl". Чтобы произвести тестовую программу, нужно
просто управлять этим скриптом и поставлять названия файлов, содержащих
испытательные модули и конфигурации, в командной строке.
Испытательные модули это файлы, которые используют суффикс
".test", а конфигурации это файлы, которые используют
суффикс ".cfg". Типичный вызов mkth3.tcl
выглядит как следующее: Вывод скрипта mkth3.tcl это программа на C,
которая содержит все нужные для запуска тесты.
Произведенная тестовая программа содержит внедрения для всех интерфейсов
поддержки, используемых испытательными модулями, и она содержит
функцию main(), которая запускает тесты. Чтобы преобразовать
тестовую программу в рабочий исполняемый файл, просто
соберите ее с SQLite: Шаг компиляции, показанный выше, просто представительный.
В рабочей установке можно было бы обычно хотеть определить параметры
оптимизации и опции времени компиляции. Для тестирования во встроенных системах mkth3.tcl
и шаги компилятора, показанные выше, выполняются на обычной рабочей станции,
используя кросскомпилятор, тогда получающаяся тестовая программа передается
на устройство, которым будут управлять. Как только тестовая программа произведена, ею управляют без аргументов,
чтобы выполнить тесты. Информация о прогрессе, а также ошибочная диагностика
появляется на стандартном выводе. Альтернативные выводы могут быть сделаны,
используя возможность времени компиляции для встроенных устройств, которые
испытывают недостаток в канале стандартного вывода.
Программа возвращает ноль при отсутствии ошибок и отличные от нуля значения,
если какие-либо проблемы были обнаружены. Типичный вывод из единственной тестовой программы TH3 похож на это: Вывод начинается с сообщения о
SQLITE_SOURCE_ID
(перепроверенный снова sqlite3_sourceid()
) для SQLite при тесте и вариантах времени компиляции, используемых, как
сообщается sqlite3_compileoption_get()
. Вывод завершается резюме результатов испытаний и повторением
SQLITE_SOURCE_ID.
Если какие-либо ошибки обнаружены, дополнительные строки
детализируют проблему. Строки сообщения об ошибке всегда начинаются с
одиночного пробела так, чтобы они могли быть быстро извлечены из
больших файлов вывода: Вывод по умолчанию показывает начало и конец каждой конфигурации и
проверяет комбинацию модуля. В примере выше "c1" и "64k" это
конфигурации, а "pager08", "build33",
"orderby01" и т. д. являются испытательными модулями.
Время компиляции и варианты во время выполнения доступны для изменения
точности вывода. Вывод может быть увеличен, показав каждый тестовый сценарий
в каждом испытательном модуле. Вывод может быть уменьшена постепенно:
исключение испытательных запусков модулей и остановок, опуская запуски
конфигурации и остановки и наконец опуская вывод вообще. TH3 идет с дополнительными сценариями TCL, что
автоматизирует процесс тестирования на рабочих станциях.
Скрипт "th3make" автоматически управляет "mkth3.tcl" и "gcc"
и затем управляет получающейся тестовой программой и проверяет результаты.
Аргументы th3make включают все испытательные модули "*.test"
и конфигурации "*.cfg", которые должны быть включены в тест.
Дополнительные опции к th3make могут заставить тестовую программу быть
собранной, используя различные компиляторы (GCC, Clang, MSVC),
чтобы использовать различные уровни детализации вывода, чтобы управлять
тестовой программой под valgrind, чтобы проверить вывод
на освещение, используя gcov, и т. д. Скрипт th3make также принимает
имена файлов "*.rc" как аргументы. Эти *.rc файлы просто коллекции
других аргументов, которые обычно используются вместе для единственной цели.
Например, файл "quick.rc" содержит ряд из восьми аргументов
th3make, которые запускают быстрый (3-минутный) тест полного охвата.
Это позволяет оператору печатать ". /th3make quick.rc" как короткий
путь к впечатыванию всех необходимых параметров командной строки.
Следующее это несколько из больше, чем 40 доступных *.rc файлов: Хранилище TH3 также включает скрипт "multitest.tcl",
другой скрипт TCL, который раньше автоматизировал тестирование TH3 на рабочих
станциях. Multitest.tcl автоматически собирает SQLite, затем управляет
./th3make неоднократно со множеством выравниваний и захватывает вывод
в сжатом итоговом экране. Типичный multitest.tcl, которым управляют,
производит примерно вот такой вывод: Как видно из вышеупомянутого, единственное выполнение
multitest.tcl вызывает th3make десятки раз
и берет между 12 и 24 часами CPU. Средний раздел вывода
показывает аргументы каждому индивидууму th3make, которым управляют,
результат и прошедшее время для этого th3make. Все собираемые продукты и
вывод для отдельных пробегов th3make захватываются
в подкаталогах для анализа после испытания. Резюме с двумя строками
в основании показывает общее количество ошибок и тестов по всем пробегам
th3make и общее количество прошедшего времени вместе с информацией
SQLITE_SOURCE_ID
для версии SQLite, которая была проверена.
Эта итоговая информация зарегистрирована в
release checklist
во время заключительного тестирования. Сокращения применяются в выводе multitest.tcl, чтобы каждый вызов th3make
соответствовал единственной строке вывода с 80 колонками.
Начальный термин "th3make" опущен.
"~" это сокращение для "-DSQLITE_" и "++" это сокращение для
"-DSQLITE_ENABLE". Следовательно, строка вывода multitest.tcl На самом деле Используя одно конкретное подмножество доступных испытательных модулей
TH3 (тесты "cov1") SQLite получил
100% тестовое покрытие отделения и 100%
MC/DC, как измерено
gcov
в Linux x86 и x86_64. Все выпуски SQLite, начиная с
version 3.6.17 (2009-08-10),
были проверены по этому стандарту. Разработчики SQLite стремятся поддерживать
100% освещение отделения и MC/DC для всех будущих выпусков SQLite. Набор тестов cov1, используемый, чтобы получить 100%
тестовое покрытие отделения, является только подмножеством тестов, в
настоящее время применяемое TH3.
Новые испытательные модули добавляются на регулярной основе. Исходное дерево TH3 содержит подготовленный скрипт
"mutation-test.tcl", который автоматизирует процесс
тестирования мутации. mutation-test.tcl заботится обо всех деталях для того, чтобы
запустить тест мутации: Тестирование мутации может быть медленным, так как каждый тест может
занять до 5 минут на быстрой рабочей станции, и есть два теста на каждую
команду перехода и более 20000 команд перехода. Усилия приложены, чтобы
ускорить операцию. Например, TH3 собран таким способом, что он выходит, как
только он находит первую ошибку, и поскольку многие мутации легко обнаружены,
много циклов происходят только за несколько секунд. Тем не менее, скрипт
mutation-test.tcl включает параметры командной строки, чтобы ограничить ряд
строк кода, проверенных так, чтобы была проверена только мутация
на блоках кода, которые недавно изменились. SQLite находится в public domain и
может использоваться для любой цели. Но TH3 требует лицензии. Даже при том, что у пользователей с открытым исходным кодом нет прямого
доступа к TH3, все пользователи получают выгоды SQLite от TH3 косвенно, так
как каждая версия SQLite утверждена, управляя TH3 на многократных платформах
(Linux, Windows, WinRT, Mac, OpenBSD) до выпуска.
Таким образом, любой использующий официальный выпуск SQLite может развернуть
свое приложение с уверенностью, что это было проверено, используя TH3.
Они просто не могут запустить повторно те тесты сами,
не покупая лицензию TH3.
Choose any three.
1. Обзор
1.1. История
2. Действие
3. Создание тестовой программы
tclsh mkth3.tcl *.test *.cfg >testprog1.c
cc -o testprog1 testprog1.c sqlite3.c
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
... 15014 lines of output omitted ....
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
grep "^ "
3.1. Сценарии автоматизации тестирования
./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
quick.rc ~DISABLE_INTRINSIC ++RTREE
th3make quick.rc -DSQLITE_DISABLE_INTRINSIC -DSQLITE_ENABLE_RTREE
4. Тестовое покрытие
5. Тестирование мутации
6. Лицензия TH3