Skip to content
Main Navigation
Автоматизированное тестирование
Интеграции
Ручное тестирование
Дашборды и аналитика
Ресурсы
Документация
Блог
События
Последнее из блога
Управление дефектами
Управление дефектами
Разбираем понятия дефекта, ошибки и отказа, чтобы эффективно описывать их в баг-репортах, учитывать в тестировании и улучшить работу команды и баг-трекера.
Тестирование производительности
Тестирование производительности
Изучаем методы и средства для оценки быстродействия системы, а также определяем, когда и как лучше всего проводить тестирование: с помощью нагрузочного или стрессового подхода.
Настройка вебхуков в ТестОпс для Slack
Настройка вебхуков в ТестОпс для Slack
Гайд по настройке вебхуков в ТестОпс на примере создания сообщений для канала в Slack.
Перейти в блог
ТарифыПартнерыСвязаться с нами
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)

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

GitHub

GitLab

Jira Data Center

Jira Software Cloud

Kaiten

Redmine

Wrike

Yandex Tracker

YouTrack

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

TestRail

Xray

Zephyr Scale

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

allurectl

AQL

API

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

SaaS

ТестОпс как SaaS

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

On this page

Обновление конфигурации для версии 5.11.3 ​

Важно

Инструкции ниже относятся к ТестОпс версии 5.x.

Внимание

Для релиза 5.11.3 требуется база данных PostgreSQL строго версии 15 или выше.

Если версия PostgreSQL отличается (ниже 15), запуск ТестОпс завершится с ошибкой.

Перед обновлением до версии 5.11.x убедитесь, что используете правильную версию PostgreSQL, и обновите параметры конфигурации.

Как обновить конфигурации ​

  1. Обновите Helm-чарт:

    shell
    helm repo update
  2. Обновите файл values.yaml в соответствии с шаблоном values.yaml актуального Helm-чарта:

    1. Откройте https://dl.qatools.ru/service/rest/repository/browse/helm-charts/testops/ и найдите TGZ-архив с номером не ниже 5.11.0.

    2. Скачайте архив.

    3. Извлеките шаблон values.yaml с помощью команды:

      shell
      tar -xzvf testops-<5.11.XX>.tgz  testops/values.yaml

      где вместо <5.11.XX> укажите номер актуальной версии Helm-чарта, например, 5.11.3.

    4. В извлеченном шаблоне values.yaml найдите раздел, связанный с источниками данных для миграций, и скопируйте параметры в ваш файл values.yaml.

      Параметры, которые вам нужны, выглядят следующим образом (в разделе datasources:):

      yaml
      migrationDatasource:
        # This section's purpose is to make the data migrations inside the database less visible for the end users.
        # System will allocate separate pool of the DB connections for the data migrations tasks and the migrations won't affect end users operations.
        # maxDBMigrationConn defines the max connections number that will be used for the migrations tasks inside the database.
        maxDBMigrationConn: 2
        # minDBMigrationIdle defines the min amount of connections to be kept in idle state. Leave it as it is unless recommended otherwise by the support
        minDBMigrationIdle: 0
        # migrationSchedulerPoolSize defines the number of parallel threads that can be used for the migration tasks.
        # The default value is 1, please do not increase this amount unless you have high workload and large database size.
        migrationSchedulerPoolSize: 1
  3. Повторно разверните приложение с обновленными параметрами.

Если у вас есть какие-либо сомнения или инструкции выше недостаточно понятны, пожалуйста, создайте запрос в службу поддержки на https://help.qatools.ru.

Pager
Next pageО продукте

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