Привет! Я Лена, руководитель проектов по тестированию в IBS. В своей статье на Хабре я собрала самое ценное — свой опыт и ошибки коллег. А здесь в посте — краткая выжимка.

1. Экономия на стенде На одном из проектов получилось, что на одном стенде оказались и мы, и разработка, и приемка. По графикам потом невозможно было понять, где наша нагрузка, а где посторонние скачки. В итоге тесты гоняли ночью, команда вымоталась. Теперь обязательно освещаем риски такого подхода Заказчику, и обсуждаем окна для тестирования.

2. Не обсуждать скоуп тестирования с архитектором 1С На одном проекте мы собирались наполнять базу под амортизацию 500 тысяч основных средств. Но в процессе получили информацию от Архитектора, что проблема ожидается уже на 100 тысячах из-за блокировок регистров. Сэкономили нам недели на наполнение базы.

3. Тестировать сразу на полном наборе данных Заказчик просил проверить перепроведение 5 млн документов. Но на наполнение базы соответствующим объемом уйдёт слишком много времени, поэтому уговорили начать с нескольких десятков тысяч. И уже на этом объеме стало понятно — скорость неудовлетворительная, нужна доработка. И не пришлось опять же тратить много времени на наполнение БД.

4. Одна база и без бэкапов Однажды у нас так разрослась база, что установка обновлений стала занимать два дня, па потом и вовсе падала с ошибкой. С тех пор заводим несколько баз под разные типы данных и всегда держим под рукой бэкапы.

5. Не оговорить SLA до старта Мой опыт показывает, что ориентиры нужны всегда. Даже очень размытые. Без них выполнения какого-либо процесса может неконтролируемо удлиниться (например, закрытие месяца мы как-то ждали 17 дней!). Теперь заранее рассказываем заказчику этот случай и обсуждаем границы процессов.

А какие ошибки в нагрузочном тестировании 1С встречались вам? Добавляйте в комментарии. Пусть они помогут другим избежать таких же факапов 🤝

Полная версия: https://habr.com/ru/companies/ibs/articles/950050/