diff options
Diffstat (limited to 'documentation/content/ru/books/developers-handbook/testing/_index.adoc')
| -rw-r--r-- | documentation/content/ru/books/developers-handbook/testing/_index.adoc | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/documentation/content/ru/books/developers-handbook/testing/_index.adoc b/documentation/content/ru/books/developers-handbook/testing/_index.adoc new file mode 100644 index 0000000000..a801c9644f --- /dev/null +++ b/documentation/content/ru/books/developers-handbook/testing/_index.adoc @@ -0,0 +1,187 @@ +--- +authors: +description: 'Регрессионное и нагрузочное тестирование' +next: books/developers-handbook/partii +params: + path: /books/developers-handbook/testing/ +prev: books/developers-handbook/policies +showBookMenu: true +tags: ["Regression", "Performance Testing", "Testing", "Tinderbox"] +title: 'Глава 6. Регрессионное и нагрузочное тестирование' +weight: 7 +--- + +[[testing]] += Регрессионное и нагрузочное тестирование +:doctype: book +:toc: macro +:toclevels: 1 +:icons: font +:sectnums: +:sectnumlevels: 6 +:sectnumoffset: 6 +:partnums: +:source-highlighter: rouge +:experimental: +:images-path: books/developers-handbook/ + +ifdef::env-beastie[] +ifdef::backend-html5[] +:imagesdir: ../../../../images/{images-path} +endif::[] +ifndef::book[] +include::shared/authors.adoc[] +include::shared/mirrors.adoc[] +include::shared/releases.adoc[] +include::shared/attributes/attributes-{{% lang %}}.adoc[] +include::shared/{{% lang %}}/teams.adoc[] +include::shared/{{% lang %}}/mailing-lists.adoc[] +include::shared/{{% lang %}}/urls.adoc[] +toc::[] +endif::[] +ifdef::backend-pdf,backend-epub3[] +include::../../../../../shared/asciidoctor.adoc[] +endif::[] +endif::[] + +ifndef::env-beastie[] +toc::[] +include::../../../../../shared/asciidoctor.adoc[] +endif::[] + +Регрессионные тесты используются для проверки определенной части системы, чтобы убедиться, что она работает как ожидается, и для предотвращения повторного появления старых ошибок. + +Инструменты для регрессионного тестирования FreeBSD можно найти в дереве исходных кодов FreeBSD в каталоге [.filename]#src/tools/regression#. + +[[testing-micro-benchmark]] +== Контрольный список для бенчмарка низкоуровневых операций + +Этот раздел содержит рекомендации по проведению корректного бенчмарка низкоуровненых операций на FreeBSD или самой FreeBSD. + +Невозможно использовать все приведенные ниже рекомендации каждый раз, но чем больше их применяется, тем лучше способность теста выявлять небольшие различия. + +* Отключить APM и любые другие манипуляции с часами (ACPI ?). +* Запускайте тесты в однопользовательском режиме. Например, man:cron[8] и другие демоны только добавляют шум. Демон man:sshd[8] также может вызвать проблемы. Если требуется доступ по SSH во время тестирования, либо отключите перегенерацию ключа SSHv1, либо завершите родительский демон `sshd` во время тестов. +* Не запускайте man:ntpd[8]. +* Если события man:syslog[3] генерируются, запустите man:syslogd[8] с пустым [.filename]#/etc/syslogd.conf#, в противном случае не запускайте его. +* Минимизируйте дисковые операции ввода-вывода, по возможности избегайте их полностью. +* Не монтируйте файловые системы, которые не требуются. +* Смонтируйте [.filename]#/#, [.filename]#/usr# и любые другие файловые системы в режиме только для чтения, если это возможно. Это исключает обновления atime на диске (и т.д.) из общей картины ввода-вывода. +* Переинициализируйте тестовую файловую систему с возможностью чтения/записи с помощью man:newfs[8] и заполните её из файла man:tar[1] или man:dump[8] перед каждым запуском. Размонтируйте и смонтируйте её перед началом теста. Это обеспечит согласованную структуру файловой системы. Для теста worldstone это применимо к [.filename]#/usr/obj# (просто переинициализируйте с помощью `newfs` и смонтируйте). Для достижения 100% воспроизводимости заполните файловую систему из файла man:dd[1] (например: `dd if=myimage of=/dev/ad0s1h bs=1m`) +* Используйте разделы man:md[4] с поддержкой malloc или предзагруженные. +* Перезагружайтесь между отдельными итерациями теста, это обеспечивает более согласованное состояние. +* Удалите все необязательные драйверы устройств из ядра. Например, если USB не нужен для теста, не включайте поддержку USB в ядре. Драйверы, которые подключаются, часто имеют работающие таймауты. +* Отключите неиспользуемое оборудование. Отсоедините диски с помощью man:atacontrol[8] и man:camcontrol[8], если диски не используются для тестирования. +* Не настраивайте сеть, если она не тестируется, или дождитесь завершения тестирования, чтобы отправить результаты на другой компьютер. +* Отключите "турбо-режимы", так как они делают тактовую частоту явно зависимой от окружающей среды. Это означает, что результаты тестирования на 100% идентичном коде могут зависеть от времени суток, употребления кофе или газировки или даже от количества людей в офисе. + +Если система должна быть подключена к общедоступной сети, следите за всплесками широковещательного трафика. Даже если они почти незаметны, они будут занимать циклы процессора. Многоадресная рассылка имеет аналогичные предостережения. +* Размещайте каждую файловую систему на отдельном диске. Это минимизирует задержки, вызванные оптимизацией перемещения головок диска. +* Минимизируйте вывод на последовательные или VGA-консоли. Запись вывода в файлы снижает дрожание. (Консоли на последовательном порту легко становятся узким местом.) Не касайтесь клавиатуры во время выполнения теста, даже нажатия kbd:[пробел] или kbd:[back-space] отражаются в числах. +* Убедитесь, что тест достаточно длинный, но не слишком. Если тест слишком короткий, возникают проблемы с временными метками. Если он слишком длинный, изменения температуры и дрейф повлияют на частоту кварцевых кристаллов в компьютере. Эмпирическое правило: больше минуты, меньше часа. +* Попытайтесь поддерживать температуру вокруг машины как можно более стабильной. Это влияет как на кварцевые резонаторы, так и на алгоритмы работы дисковых накопителей. Для получения действительно стабильных часов рассмотрите возможность использования стабилизированного тактового сигнала. Например, используйте OCXO + PLL и подавайте выходной сигнал в тактовые схемы вместо кварцевого резонатора на материнской плате. Для получения дополнительной информации по этому вопросу свяжитесь с {phk}. +* Выполните тест как минимум 3 раза, но лучше запустить более 20 раз как для кода "до", так и для кода "после". По возможности чередуйте запуски (т.е. не следует запускать 20 раз "до", а затем 20 раз "после"), это поможет выявить влияние окружения. Не чередуйте строго 1:1, а лучше 3:3, чтобы можно было обнаружить эффекты взаимодействия. ++ +Хороший шаблон: `bababa{bbbaaa}*`. Это дает подсказку после первых 1+1 прогонов (так что можно остановить тест, если всё идет совсем не так), стандартное отклонение после первых 3+3 (дает хорошее представление, стоит ли проводить длительный прогон), а также тренды и показатели взаимодействия позже. +* Используйте man:ministat[1], чтобы определить, являются ли числа значимыми. Рекомендуется приобрести книгу "Cartoon guide to statistics" ISBN: 0062731025, особенно если вы забыли или никогда не изучали стандартное отклонение и t-критерий Стьюдента. +* Не используйте фоновый man:fsck[8], если тест не является бенчмарком фонового `fsck`. Также отключите `background_fsck` в [.filename]#/etc/rc.conf#, если бенчмарк не запускается как минимум через 60+«время работы ``fsck``» секунд после загрузки, так как man:rc[8] пробуждается и проверяет, нужно ли запускать `fsck` для каких-либо файловых систем, когда включен фоновый `fsck`. Аналогично, убедитесь, что нет оставшихся снимков, если только бенчмарк не является тестом со снимками. +* Если тесты производительности показывают неожиданно низкие результаты, проверьте такие факторы, как высокий объем прерываний из неожиданного источника. Сообщалось, что некоторые версии ACPI могут "вести себя неправильно" и генерировать избыточные прерывания. Для диагностики необычных результатов тестов сделайте несколько снимков `vmstat -i` и поищите что-то необычное. +* Будьте внимательны к параметрам оптимизации для ядра и пользовательского пространства, а также отладки. Легко упустить что-то и позже понять, что тест сравнивал не одно и то же. +* Никогда не проводите тестирование производительности с включёнными параметрами ядра `WITNESS` и `INVARIANTS`, если тест не направлен на оценку производительности именно этих функций. `WITNESS` может привести к снижению производительности на 400% и более. Аналогично, параметры userspace man:malloc[3] по умолчанию отличаются в -CURRENT от тех, что поставляются в релизах. + +[[testing-tinderbox]] +== Tinderbox для исходного текста FreeBSD + +Исходный Tinderbox состоит из: + +* Скрипта сборки [.filename]#tinderbox#, который автоматизирует выгрузку определённой версии исходного кода FreeBSD и её сборку. +* Скрипта-супервизора [.filename]#tbmaster#, который отслеживает отдельные экземпляры Tinderbox, записывает их вывод и отправляет уведомления о сбоях по электронной почте. +* Скрипта CGI с именем [.filename]#index.cgi#, который читает набор журналов tbmaster и представляет их в виде удобочитаемой HTML-сводки. +* Набора серверов сборки, которые постоянно тестируют последние изменения наиболее важных веток кода FreeBSD. +* Веб-сервера, хранящего полный набор журналов Tinderbox и отображающий актуальную сводку. + +Скрипты поддерживаются и были разработаны {des}, и сейчас написаны на Perl, что стало шагом вперед по сравнению с их первоначальной версией в виде shell-скриптов. Все скрипты и конфигурационные файлы хранятся в https://www.freebsd.org/cgi/cvsweb.cgi/projects/tinderbox/[/projects/tinderbox/]. + +Для получения дополнительной информации о скриптах tinderbox и tbmaster на данном этапе обратитесь к соответствующим руководствам: tinderbox(1) и tbmaster(1). + +== Скрипт index.cgi + +Скрипт [.filename]#index.cgi# генерирует HTML-сводку журналов tinderbox и tbmaster. Хотя изначально он предназначался для использования в качестве CGI-скрипта, как следует из его названия, этот скрипт также может быть запущен из командной строки или из задачи man:cron[8], в таком случае он будет искать логи в директории, где расположен сам скрипт. Он автоматически определяет контекст, генерируя HTTP-заголовки при запуске в качестве CGI-скрипта. Он соответствует стандартам XHTML и использует CSS для стилизации. + +Скрипт начинает работу в блоке `main()`, пытаясь проверить, что он выполняется на официальном сайте Tinderbox. Если это не так, создается страница с указанием, что это не официальный сайт, и предоставляется URL официального сайта. + +Далее выполняется сканирование каталога журналов для получения перечня конфигураций, веток и архитектур, для которых существуют файлы журналов, чтобы избежать жесткого задания списка в скрипте и потенциального появления пустых строк или столбцов. Эта информация извлекается из имен файлов журналов, соответствующих следующему шаблону: + +[.programlisting] +.... +tinderbox-$config-$branch-$arch-$machine.{brief,full} +.... + +Конфигурации, используемые на официальных серверах сборки Tinderbox, названы в соответствии с ветками, которые они собирают. Например, конфигурация `releng_8` используется для сборки `RELENG_8`, а также всех поддерживаемых веток выпусков. + +После успешного завершения всей процедуры запуска для каждой конфигурации вызывается `do_config()`. + +Функция `do_config()` генерирует HTML для отдельной конфигурации Tinderbox. + +Он работает, сначала создавая строку заголовка, затем перебирая каждую сборку ветки с указанной конфигурацией, формируя одну строку результатов для каждой следующим образом: + +* Для каждого элемента: + +** Для каждой машины в рамках этой архитектуры: + +*** Если существует краткий файл журнала, то: + +**** Вызвать `success()`, чтобы определить результат сборки. +**** Вывести размер изменения. +**** Вывести размер краткого файла журнала со ссылкой на сам файл журнала. +**** Если также существует полный файл журнала, то: + +***** Вывести размер полного файла журнала со ссылкой на сам файл журнала. + +*** В противном случае: + +**** Нечего не выводить. + +Упомянутая выше функция `success()` проверяет краткий лог-файл на наличие строки "tinderbox run completed", чтобы определить, был ли сборка успешной. + +Конфигурации и ветви сортируются в соответствии с их рангом. Это вычисляется следующим образом: + +* `HEAD` и `CURRENT` имеют ранг 9999. +* `RELENG_x` имеет ранг __``xx``__99. +* `RELENG_x_y` имеет ранг _xxyy_. + +Это означает, что `HEAD` всегда имеет наивысший приоритет, а ветви `RELENG` ранжируются в числовом порядке, причём каждая ветвь `STABLE` имеет более высокий приоритет, чем ветви выпусков, ответвлённые от неё. Например, для FreeBSD 8 порядок от наивысшего к низшему будет следующим: + +* `RELENG_8` (ранг ветки 899). +* `RELENG_8_3` (ранг ветки 803). +* `RELENG_8_2` (ранг ветки 802). +* `RELENG_8_1` (ранг ветки 801). +* `RELENG_8_0` (ранг ветки 800). + +Цвета, которые Tinderbox использует для каждой ячейки в таблице, определяются CSS. Успешные сборки отображаются зелёным текстом; неудачные сборки отображаются красным текстом. Цвет блекнет со временем с момента соответствующей сборки, приближаясь к серому каждые полчаса. + +== Официальные серверы сборки + +Официальные серверы сборки Tinderbox размещены на площадке http://www.sentex.ca[Sentex Data Communications], которая также предоставляет хостинг для кластера Netperf FreeBSD. + +В настоящее время работают три сервера сборки: + +_freebsd-current.sentex.ca_ собирает: + +* `HEAD` для amd64, arm, i386, i386/pc98, ia64, mips, powerpc, powerpc64 и sparc64. +* `RELENG_9` и поддерживаемые ветки 9._X_ для amd64, arm, i386, i386/pc98, ia64, mips, powerpc, powerpc64 и sparc64. + +_freebsd-stable.sentex.ca_ собирает: + +* `RELENG_8` и поддерживаемые ветки 8._X_ для amd64, i386, i386/pc98, ia64, mips, powerpc и sparc64. + +_freebsd-legacy.sentex.ca_ собирает: + +* `RELENG_7` и поддерживаемые ветки 7._X_ для amd64, i386, i386/pc98, ia64, powerpc и sparc64. + +== Официальный сайт со сводками + +Сводки и журналы с официальных серверов сборки доступны в сети по адресу http://tinderbox.FreeBSD.org[http://tinderbox.FreeBSD.org], размещены на {des} и настроены следующим образом: + +* Задание man:cron[8] проверяет серверы сборки через регулярные интервалы и загружает все новые файлы журналов с помощью man:rsync[1]. +* Apache настроен на использование [.filename]#index.cgi# в качестве `DirectoryIndex`. |