Skip to content
Main Navigation
Автоматизированное тестирование
Централизованное управление автотестами и результатами
Интеграции
Готовые коннекторы с CI/CD, трекерами и репозиториями
Ручное тестирование
Планирование, выполнение и контроль ручных проверок в одном месте
Дашборды и аналитика
Визуализация данных, отчёты и метрики тестов в реальном времени
Ресурсы
Документация
Материалы по установке, настройке и подключению интеграций в ТестОпс
Блог
Статьи и руководства по стратегиям и инструментам тестирования
События
Живое общение с командой ТестОпс на вебинарах и конференциях
Истории клиентов
Реальные кейсы и истории внедрения с результатами из первых рук
Последнее из блога
Искусственный интеллект в тестировании | Часть 1
Искусственный интеллект в тестировании | Часть 1
Пошаговая инструкция по автоматизации тестирования: настройка окружения, интеграция с GitHub Actions и ТестОпс, использование Cursor IDE и MCP.
Настройка вебхуков в ТестОпс для Telegram
Настройка вебхуков в ТестОпс для Telegram
Гайд по настройке вебхуков в ТестОпс на примере создания сообщений для канала в Telegram.
Сокращение технического долга в UI-тестах
Сокращение технического долга в UI-тестах
Обзор причин нестабильности, практик повышения надёжности, архитектурных решений и возможностей платформы ТестОпс для контроля качества.
Перейти в блог
ТарифыПартнерыСвязаться с нами
Sidebar Navigation

Описание ТестОпс

О продукте

Информация о релизах

Миграция с других решений

Термины и определения

Часто задаваемые вопросы

Установка ТестОпс

Архитектура

Установка и первый запуск

Обзор

Kubernetes

Docker Compose

DEB-пакеты

RPM-пакеты

База данных

S3-совместимое хранилище

Конфигурация

Обзор

Сеть

Аутентификация

Обзор

Локальная аутентификация

LDAP

OpenID и Azure AD

OpenID и Keycloak

SAML 2.0

Настройка SMTP

Перенос данных в другой инстанс

Начало работы

1. Создайте проект

2. Запустите ручной тест

3. Запустите автотест

4. Создайте комбинированный запуск

5. Обработайте результаты тестов

Обзор ТестОпс

Обзор

Дашборды

Тест-кейсы

Общие шаги

Тест-планы

Запуски

Результаты тестов

Дефекты

Джобы

Меню пользователя

Тест-кейсы

Статусы воркфлоу

Сценарий ручного теста

Параметры ручного теста

Вложения

Теги

Тестовые слои

Ссылки

Задачи из таск-трекеров

Сторонние тест-кейсы

Участники

Связанные тест-кейсы

Кастомные поля

Ключи маппинга

Импорт

Запуски

Окружение

Обновление метаданных

Сравнение запусков

Категории ошибок

Проект

Обзор

Управление доступом

Деревья

Вебхуки

Администрирование

Обзор

Участники

Группы

Очистка данных

Журналы аудита пользователей

Интеграции

Обзор

CI-системы

AWS CodePipeline

Azure DevOps

Bamboo

Bitbucket

CircleCI

GitHub

GitLab

Jenkins

TeamCity

TeamCity (allurectl)

Таск-трекеры

Битрикс24

EvaProject

GitHub

GitLab

Jira Data Center

Jira Software Cloud

Kaiten

Redmine

Wrike

Yandex Tracker

YouTrack

Системы управления тестированием

TestRail

Xray

Zephyr

Экосистема ТестОпс

allurectl

AQL

API

Устранение неполадок

SaaS

ТестОпс как SaaS

Миграция в облако ТестОпс

Техническая поддержка

On this page

База данных ​

Требования к базе данных ​

Производственная среда ​

База данных должна быть развернута как отдельное решение вне ТестОпс. Производительность базы данных, находящейся в поде с PVC (Persistent Volume Claim) или в контейнере, ухудшается при высокой нагрузке, вызванной автотестами. Такое развертывание приемлемо для демонстрационных целей или при проверке концепции (PoC), но для производственной среды с результатами автотестов база данных должна быть развернута как отдельный кластер.

Аппаратное обеспечение ​

Для хранения данных в базе данных используйте только SSD, предпочтительно корпоративного класса. ТестОпс создает значительную нагрузку на базу данных при обработке результатов тестов и выполнении запросов данных, и HDD не способны справиться с такой нагрузкой. При использовании HDD производительность системы будет снижаться с течением времени (через 6-8 месяцев использования). В дальнейшем ответы базы данных на статистические запросы будут потреблять все доступные соединения из-за долгого времени отклика, что негативно скажется на общей производительности системы и пользовательском опыте.

Проблемы с производительностью ТестОпс, работающего на HDD, не могут быть решены службой поддержки.

Версия PostgreSQL ​

ТестОпс поддерживает базу данных PostgreSQL только версии 15 или выше:

  • Минимальная поддерживаемая версия — 15.
  • Рекомендуемые версии — 15 и 16.
  • Мы не проводили внутреннее тестирование версии 17, поэтому мы не можем гарантировать корректную работу ТестОпс с этой версией.

Рекомендации для базы данных ​

Параметры PostgreSQL ​

ТестОпс активно использует базу данных и объекты хранилища на этапах обработки результатов автотестов и генерации виджетов на проектных дашбордах.

Мы составили рекомендации для настройки базы данных, основанные на опыте работы с высоконагруженными инстансами ТестОпс в средах наших клиентов.

random_page_cost ​

Настройка параметра random_page_cost значительно влияет на производительность базы данных PostgreSQL и зависит от типа используемых дисков хранения.

Возможные значения параметра:

  • При использовании SSD установите 1.5.

    Для очень быстрых SSD, таких как AWS gp2/gp3 с высокой IOPS, установите 1.2.

    Не используйте с SSD значение по умолчанию 4.0.

  • При использовании HDD установите значение по умолчанию 4.0. Всеми средствами избегайте использования HDD в качестве хранилища базы данных.

work_mem ​

Параметр work_mem зависит от оперативной памяти, доступной для базы данных, и максимального количества сеансов, разрешенных для базы данных.

Важно

Новое значение параметра work_mem потребует перезапуска базы данных.

Формула для расчета work_mem:

work_mem = db_available_ram x 0.2 / num_of_testops_service_instances x connection_pool_size_per_instance,

где:

  • db_available_ram — количество оперативной памяти, доступной базе данных;
  • num_of_testops_service_instances — количество инстансов сервиса testops;
  • connection_pool_size_per_instance — размер пула соединений для инстанса, по умолчанию равен 10.

Совет

Например, при исходных данных:

  • 64 ГБ оперативной памяти для базы данных;
  • 10 инстансов сервиса testops;
  • размер пула соединений, равный 10,

значение work_mem = 64 000 x 0.2 / 100 = 128 МБ.

effective_io_concurrency ​

Значение для параметра effective_io_concurrency:

  • 64 при использовании SSD;
  • 1 при использовании HDD (значение по умолчанию).

shared_buffers ​

Рекомендуется установить параметр shared_buffers на уровне минимум 50% от доступной оперативной памяти. Для лучшей производительности можно установить до 75% от доступной оперативной памяти, однако следует следить за ее состоянием и при необходимости снизить параметр (например, обратно до 50%) при высокой конкуренции за ее ресурсы.

AWS RDS ​

Если вы используете AWS RDS, убедитесь, что IOPS не ограничен.

Для клиентов со средним/большим объемом данных AWS RDS должен иметь не менее 3 000 IOPS, что равно 1 000 ГБ хранилища gp2.

Создание базы данных ​

ТестОпс использует одну базу данных для управления пользователями и хранения всех данных по тестам.

  1. Авторизуйтесь как администратор базы данных.

    bash
    # переключитесь на пользователя postgres на сервере базы данных
    sudo su postgres
    # подключитесь к серверу базы данных
    psql

    Вы можете использовать любой другой способ подключения, который вам удобен.

  2. Создайте базу данных.

    Важно

    Рекомендуется изменить как минимум пароль для пользователя testops.

    В примере ниже testops — имя пользователя базы данных и имя самой базы данных.

    sql
    # создайте нового пользователя базы данных
    CREATE USER testops WITH ENCRYPTED PASSWORD 'PaSSw0rd';
    # создайте базу данных
    CREATE DATABASE testops TEMPLATE template0 ENCODING 'utf8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
    # подключитесь к базе данных
    \c testops
    # предоставьте все привилегии пользователю testops на базе данных testops
    GRANT ALL PRIVILEGES ON DATABASE testops TO testops;
    # предоставьте все привилегии на схему public
    GRANT ALL PRIVILEGES ON SCHEMA public TO testops;
    \q

Обновление базы данных ​

Переход на версию ТестОпс 5.20.0 или выше ​

Если версия вашего инстанса ТестОпс ниже 5.20.0, при обновлении на версию 5.20.0 или выше приложение разово запустит скрипты, которые создадут индексы на одни из самых больших таблиц в вашей базе данных. Это необходимо для улучшения производительности ТестОпс.

Создание индексов на таблицы — ресурсоемкий процесс, время выполнения которого зависит от объема таблиц в вашей базе данных. На этот период инстанс ТестОпс будет недоступен для работы.

Чтобы избежать временного простоя, вы можете заранее запустить скрипты на текущей версии вашего инстанса ТестОпс. Для этого настоятельно рекомендуем ознакомиться с инструкцией по созданию индексов, где приведены пошаговые рекомендации для администраторов серверной версии ТестОпс. Выполнив шаги инструкции перед установкой версии 5.20.0 или выше, вы сможете установить обновление без прерывания работы инстанса — повторный запуск скриптов не потребуется.

Альтернативная схема базы данных ​

Внимание

В подавляющем большинстве случаев настройки, описанные ниже, не нужны и могут привести к непредсказуемым результатам и невозможности поддержки при неправильном выполнении. Пожалуйста, не изменяйте схему по умолчанию, если правила вашей организации не требуют иного.

По умолчанию ТестОпс использует схему базы данных public. В случае, если правила вашей организации не позволяют использовать схему public, это поведение можно изменить.

Схема базы данных должна быть определена до развертывания и должна оставаться неизменной во время использования системы.

Установка альтернативной схемы базы данных ​

  1. Перед развертыванием ТестОпс добавьте схему базы данных в соответствии с вашими правилами.

    • В качестве примера мы используем схему default.
    • Владельцем должен быть пользователь, который используется в конфигурации подключения к базе данных TestOps.
    • Пользователь базы данных должен иметь все разрешения для базы данных.
    • Пользователь базы данных должен иметь все привилегии для созданной схемы (GRANT ALL ON SCHEMA default TO testops;).
  2. Перед развертыванием ТестОпс добавьте в его конфигурацию параметр для сервиса testops — ALLURE_DB_SCHEMA=default.

    Обновите файл values.yaml:

    yaml
    env:
      open:
        ALLURE_DB_SCHEMA: default
    <...>

Разделение пулов соединений ​

Примечание

Информация актуальна только для развертываний в Kubernetes.

По умолчанию ТестОпс использует один пул соединений для всех типов запросов к базе данных. Его размер определяется параметром datasources.mainDatasource.appMaxDBConnection.

В среде с высокой нагрузкой может понадобиться не только увеличить общее количество соединений, но и убедиться, что более длительные операции не занимают ресурсы у более быстрых и важных. Это можно сделать, включив отдельные пулы загрузки и аналитические пулы. Аналитический пул также можно настроить для использования альтернативного источника данных.

  • Пул загрузки, если он включен, будет использоваться при загрузке новых результатов тестов в ТестОпс.

    Чтобы включить пул загрузки:

    1. Установите параметру datasources.uploaderDatasource.enabled значение true.
    2. Установите параметр datasources.uploaderDatasource.appMaxDBConnection на максимальное количество соединений для загрузки.
  • Аналитический пул, если он включен, будет использоваться для некоторых запросов к агрегированным данным только для чтения. Обычно для аналитики используется отдельная база данных с настроенной репликацией между двумя базами данных.

    Чтобы включить аналитический пул:

    1. Установите параметру datasources.analyticsDatasource.enabled значение true.
    2. Установите параметр datasources.analyticsDatasource.appMaxDBConnection на максимальное количество аналитических соединений.
    3. Укажите учетные данные PostgreSQL в параметре datasources.analyticsDatasource.* аналогично основным настройкам базы данных.
Pager
Previous pageRPM-пакеты
Next pageS3-совместимое хранилище

Logo © 2025 Все права защищены. Сайт принадлежит компании ООО «Инструменты тестирования»