---
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`.
