В этой статье речь пойдет о том, как мы автоматизируем процессы разработки и тестирования технологической платформы «1С:Предприятие 8».
Платформа «1С:Предприятие 8» представляет собой набор инструментов для создания бизнес-приложений и среды их исполнения.
Это большой (более десятков миллионов строк кода) проект на C++, Java и JavaScript. Над ним работают десятки программистов, одновременно разрабатывая и поддерживая до 10 различных версий продукта.
Платформа работает на различных версиях ОС и баз данных:
- ОС: Windows, Linux, MacOS
- СУБД: MS SQL, PostgreSQL, IBM DB2, Oracle, собственные файловые СУБД.
- Мобильная ОС: Android, iOS, Windows
- Тонкий клиент
- Толстый клиент
- Веб-клиент (Internet Explorer, Microsoft Edge, Chrome, Firefox, Safari)
- Мобильный клиент
Общие задачи автоматизации
Цели, которые мы ставим перед собой:- Максимально автоматизируйте и ускорьте рутинные задачи разработки и тестирования.
- Непрерывное тестирование с минимальными усилиями по тестированию
- Добавляйте в версию продукта только качественный новый код
- Не ломайте старый функционал
- Довести количество существенных дефектов в выпускаемой платформе до нуля.
- Обнаруживайте проблемы на ранней стадии, чтобы минимизировать затраты на расследование и исправление.
Одновременная разработка нескольких версий платформы В своей работе мы применяем практику непрерывной интеграции (CI); Объединение рабочих копий кода в общую основную ветку происходит несколько раз в день; после слияния производится автосборка и автотестирование модифицированного проекта.
Если при сборке или тестировании возникают проблемы, модифицированный код возвращается на доработку.
Процессы разработки для одной версии платформы
Проблемы, стоящие перед CI:
- Сборка
- Серия сборок разных типов и последующее тестирование модифицированных версий в рамках непрерывного цикла.
Для ускорения расследования единичных изменений результатов тестов мы используем инкрементную компиляцию — компилируется только то, что изменилось и прямые зависимости.
Для полного цикла испытаний сборки собираются полностью.
Необходимость и последовательность дополнительных сборок определяют по результатам испытаний, предварительный анализ которых автоматизирован.
- Параллельная проверка существенных изменений (интеграционных сборок).
Если инженер считает изменения существенными, он сначала сливает их в отдельную ветку, собирает ее и запускает все тесты.
Если все тесты пройдены успешно, в основную ветку вносятся изменения.
- Обнаружение ошибок максимально быстро, по возможности автоматически
- Автоматизация рутинных действий (анализ дампов, миграция изменений между ветками, протоколирование ошибок)
- Серия сборок разных типов и последующее тестирование модифицированных версий в рамках непрерывного цикла.
- Многоуровневое тестирование
- Регрессия
- Модульные тесты
- Интеграционное тестирование
- Нагрузочные тесты
- Визуальные тесты
- Тесты обратной совместимости
- Тестирование сценариев
- Прогрессивный
- В основном функциональный
- Приемочное тестирование
- Ход тестирования и изменения
- Сюда также входит ручное тестирование.
- Сюда также входит ручное тестирование.
Полный цикл автоматического тестирования занимает около суток, что, к сожалению, для некоторых задач недопустимо долго (балансировка ресурсов тестирования ускоряет процесс при наличии свободных ресурсов — если таковые имеются на данный момент).
Чтобы нейтрализовать этот негативный эффект, мы разрабатываем «облегченную» версию тестов, которая должна запускаться за час и затрагивать около 80% функционала.
Таким образом, мы можем получить общее представление о том, насколько эффективна сборка, гораздо быстрее.
Бывают случаи, когда вам не понадобится даже час.
Теперь при тестировании учитываются результаты предыдущих циклов тестирования, а проблемные/новые/исправленные тесты запускаются с высоким приоритетом, что позволяет увидеть прогресс изменения самого изменяемого функционала сразу в начале тестирования.
Для некоторых типов сборок принято правило «10 сбоев», когда серия тестов автоматически прерывается при достижении 10 сбоев в пределах одной серии, чтобы освободить ресурсы для тестирования других сборок/других версий и т.п.
У нас около 70 физических серверов и около 1500 виртуальных серверов, задействованных в сборке и тестировании.
Инструменты
Дженкинс
Мы используем Дженкинс как система непрерывной интеграции.В периоды пиковой нагрузки выполняет 20 сборок платформ в день; одна полная сборка занимает около 1,5 часов, тестирование – от 1 часа.
Сборка ведется параллельно по архитектурам (Windows, Linux, macOS), каждая сборка выполняется в сотнях потоков одновременно.
Такой подход несколько лет назад позволил сократить время сборки одной версии платформы со всеми архитектурами с 8 часов до 80 минут, и мы не собираемся на этом останавливаться.
Через веб-сервисы Jenkins интегрируется с нашим трекером задач «База задач» (написан на платформе «1С:Предприятие») и в случае возникновения проблем автоматически заносит ошибки непосредственно в «Базу задач», прикрепляя ссылки на логи и тестирование.
артефакты.
Дженкинс также готовит платформу к публикации, фильтрует и парсит дампы при необходимости.
Дженкинс также управляет тестированием, позволяя реализовывать сколь угодно сложные сценарии на произвольных конфигурациях оборудования, включая большое количество виртуальных машин, а также выполняет дополнительную работу, например, доставляет и устанавливает платформу на 1500 серверов до 70 раз в день.
Апач JMeter
ты JMeter имеет очень ценное качество – низкие требования к оборудованию для эмуляции работы большого количества пользователей.JMeter также позволяет генерировать смешанные нагрузки за один тест — HTTP, SOAP, JDBC, LDAP, SMTP, TCP. В частности, мы используем JMeter для тестирования производительности кластера приложений и его отдельных компонентов, а также для нагрузочного тестирования кластера приложений на большом количестве (до 10 000) пользователей.
Для данного тестирования достаточно одного сервера базы данных, двух серверов 1С и одного нагрузочного сервера.
У нас есть 4 тестовых стенда, на которых тестируется одиночный кластер, кластер в отказоустойчивой и неотказоустойчивой конфигурациях; Для тестирования этих конфигураций нам нужны всего две физические машины.
Графики производительности от JMeter
Испытательный центр
Для более сложных испытаний мы используем наш продукт Испытательный центр (включен в Корпоративный пакет инструментов ).Тестовый центр — конфигурация на платформе «1С:Предприятие 8»; он позволяет описывать сценарии многопользовательского тестирования, запускать их автоматически и отслеживать ход их выполнения.
Мы запускаем Испытательный Центр на так называемых конвейерах; один конвейер состоит из 2-х мощных физических серверов, на которых расположены виртуальные машины:
- 1 сервер приложений 1С
- 1 сервер базы данных
- 1 сервер лицензирования
- 40 серверов с клиентскими сессиями
В одном конвейере содержится либо 100 очень быстрых клиентов (выполняющих операции без пауз), либо 1000 клиентов, близких к реальным пользователям (эмулирующих работу обычного человека, с паузами между действиями).
Конвейеры конструируют стандартные варианты стендов:
- маленький
- средний
- большой
Конфигурации различаются составом серверов и отказоустойчивостью.
Серверы могут быть на Linux и Windows. Базы для тестирования (как и тестовые скрипты) подготовлены в двух вариантах:
- облако, для технологий 1cсвежий (база данных с большим количеством относительно небольших областей данных)
- CORP, для крупных реализаций (большая база данных)
- 1с бухгалтерия
- Управление нашей компанией
- Заработная плата и управление персоналом
- Заработная плата и управление персоналом
- 1С:ERP Управление предприятием 2
Нагрузочные тесты доступны в версиях на 100, 200, 400, 3000 и 10000 пользователей.
В разных конфигурациях рабочих мест количество серверов в кластере варьируется от 1 до 6. Для запуска тестов на 10 000 пользователей в одной базе используются два рабочих сервера приложений 1С.
Каждая конфигурация кластера автоматически настраивается из сотен параметров в начале каждого теста.
Фактически можно считать, что стенд полностью готов к работе в автоматическом режиме, поскольку:
- платформа доставлена
- сценарии доставлены
- кластер настраивается
- база данных загружается
- Конфигурационные файлы настраиваются (по заданным параметрам)
- готовятся публикации информационных баз
Также у нас есть сценарии тестирования реструктуризации (обновления версии продукта, меняющего структуру базы данных).
Мы тестируем реструктуризацию на тех же стендах.
После завершения теста проверяется конечный результат – данные в базе данных должны быть обновлены корректно, а структура базы данных должна соответствовать новой версии.
И старые, и новый механизм реструктуризации.
Во время нагрузочных тестов мы автоматически собираем и анализируем:
- все ошибки по данным Тестового Центра
- исключения из технологического журнала платформы
- все запросы из журнала технологий платформы
- все ошибки из журнала
- все замеры выполняемых операций с технологической информацией об их выполнении
- все данные о загрузке оборудования
Все данные сохраняются и агрегируются в специальной базе данных со статистикой и результатами испытаний.
ЭКран испытательного центра
Также мы проводим нагрузочное тестирование 10 000 пользователей в конфигурации «1С:ERP Управление предприятием 2» на отказоустойчивом кластере с моделированием сбоев оборудования, сбоев сети, нехватки памяти, ресурсов ЦП и дискового пространства.
Это большой сценарий тестирования, в котором на протяжении всего теста моделируется зависание процессов сервера 1С, часть процессов «убивается» утилитой Taskkill, отключается и восстанавливается сеть и т.д. В рамках тестирования , пользовательские сценарии работы отрабатываются в разных подсистемах — склад, закупки, продажи, взаиморасчеты и т. д. Нагрузочный тест ERP предполагает около 400 ключевых операций, а длительность теста составляет несколько часов.
Один из скриптов тестирования ERP (работает параллельно с другими скриптами)
Сравнение производительности конфигурации
Наш внутренний инструмент «Сравнение производительности конфигураций» (CPC) работает поверх описанных систем, позволяя сравнивать производительность:- разные версии одной и той же конфигурации на одной платформе
- две версии платформы при использовании одной и той же конфигурации
- разные версии базы данных/ОС с одной и той же платформой/конфигурацией
Система позволяет автоматически обнаруживать возникновение ошибки, изменение нагрузки на серверы, изменение длительности запросов (или появление запросов, которых раньше не было).
Мы анализируем как ухудшение, так и улучшение, что может быть симптомом проблемы.
Систему можно использовать для сравнения.
- версии конфигурации,
- версии платформы,
- версии СУБД,
- любые настройки
Визуальное тестирование
Все вышеперечисленные инструменты эмулируют работу пользователей, вызывая соответствующие методы встроенных объектов тестируемых конфигураций, совершая обращения к веб- и HTTP-сервисам и т. д. Но также крайне важно тестировать именно то, что на самом деле видит пользователь., особенно пользователь, работающий через веб-клиент (где браузеру может потребоваться довольно значительное время для отображения интерфейса).
Мы столкнулись с ситуацией, когда производительность по автоматизированным тестам при переходе на новую версию не менялась, но когда мы сажали человека с секундомером, то на старой версии он получал одни цифры, а на новой - совсем другие.
Это связано, в частности, со временем отрисовки графического интерфейса, которое по каким-то причинам могло измениться в новой версии.
Мы написали собственный инструмент, позволяющий проводить визуальное тестирование практически любого приложения.
Инструмент записывает действия пользователя, запустившего приложение, в файл сценария.
Инструмент также записывает изображение рабочей области экрана.
При мониторинге новых версий клиента скрипты проигрываются без участия пользователя.
При воспроизведении сценария инструмент, прежде чем имитировать нажатия клавиш или кнопок мыши, ожидает появления того же изображения на экране (с точностью до пикселя), что и в записанном сценарии.
Инструмент также измеряет производительность приложений с точностью до 25 миллисекунд и записывает результаты в журнал для дальнейшего автоматического сравнения.
В некоторых случаях мы зацикливаем части скрипта (например, повторяем ввод ордера несколько раз), чтобы проанализировать ухудшение времени выполнения скрипта.
Данное тестирование, помимо измерения производительности, также позволяет нам быть уверенными, что в новой версии платформы пользователь увидит в тонком клиенте и в браузере те же экраны, что и в предыдущей версии приложения.
Пример запуска скрипта ввода заказа в конфигурации «Управление нашей компанией» - заказ вводится 5 раз; Вот реальная скорость работы платформы 1С:Предприятие, если пользователь мгновенно реагирует на доступность интерфейса:
Функциональное тестирование
Мы также активно развиваем функциональное тестирование.Мы тестируем комбинации основных версий ОС и баз данных, для каждой такой комбинации у нас есть свой набор виртуальных машин, весь набор комбинаций образует один конвейер; автоматическое добавление в этот конвейер новых комбинаций ОС и БД.
Каждый функциональный тест превращается в набор задач, выполняемых во всех возможных комбинациях; задания выполняются первыми доступными стендами.
проходят испытания Конфигуратор (среда разработки прикладных решений 1С), встроенные языковые функции, язык запросов и т.д. При тестировании Конфигуратора мы проверяем большинство команд, доступных в командной строке Конфигуратора.
Кроме того, у нас есть специальная библиотека (мы не поставляем ее извне), позволяющая тестировать внутреннюю логику Конфигуратора, доступную только через пользовательский интерфейс, не прибегая к прямому UI-тестированию.
Таким образом, тестируется большинство функций по работе с расширениями конфигурации, функционал сравнения/объединения и другой функционал Конфигуратора.
В целях тестирования в этом режиме доступно написание скриптов на языке 1С.
В сценарии доступны специальные объекты для целей тестирования.
Запуск конфигуратора в этом режиме можно совместить в одном тесте с запуском клиентского приложения.
Это позволяет использовать данный режим не только как средство тестирования конфигуратора, но и как способ настройки тестовой среды.
Ешь свой собственный корм для собак
На платформе «1С:Предприятие» написан ряд наших внутренних инструментов, которые мы используем в повседневной работе.Они работают на последних сборках платформы.
Ниже мы поговорим о двух из них – «База данных задач» и «Отчеты сотрудников».
База данных задач
Наш внутренний трекер задач «База задач» представляет собой конфигурацию, написанную на платформе «1С:Предприятие».Это 21 независимые базы данных (часть баз рабочие, часть тестовые) на разных версиях платформы, с разными ОС и СУБД, базы синхронизируются через платформу механизм обмена данными ; Версии платформы обновляются ежедневно, а на некоторых серверах устанавливаются экспериментальные версии платформы с некоторыми новыми функциями.
Новый функционал платформы, который был зафиксирован, можно будет протестировать на Базе задач уже на следующий день.
Разные экземпляры базы данных работают с разными серверными средами (ОС, СУБД) и с разными версиями платформы, а пользователи также входят в систему с разных клиентов (тонкий клиент, мобильный клиент ) и через веб-клиент из разных браузеров.
Таким образом, разные версии платформы тестируются в разных средах.
Отчеты сотрудников
«Отчеты сотрудников» — это тайм-трекер для учета рабочего времени, который используют сотрудники отдела разработки платформы «1С:Предприятие».Он работает на последней сборке платформы.
«1С:Документооборот»
Стандартное решение «1С:Документооборот» , которым пользуются все сотрудники нашей компании, мы также используем его с новыми, еще не выпущенными версиями платформы.
Платформенные тесты в прикладных решениях
Наряду с автоматическими визуальными тестами популярных прикладных решений («Бухгалтерия предприятия», «Управление нашей компанией», «Зарплата и управление персоналом» и др.) мы проводим ручные тесты: сценарное, визуальное, ручное тестирование согласно плану тестирования основные дела.
После достижения определенного уровня качества платформы мы просим разработчиков приложений перейти к разработке на новой версии платформы и протестировать свои продукты на следующей версии.
Бета-тестирование платформы партнерами
Некоторые наши партнеры проявляют интерес к использованию ранних, еще не вышедших версий платформы «1С:Предприятие».Такие партнеры подписывают контракт с компанией 1С.
Соглашение о неразглашении , получите доступ к сборкам платформы до выхода тестовой версии и получите возможность использовать последнюю версию платформы в реальных условиях.
Это позволяет партнерам обнаружить проблемы в платформе на ранней стадии и быть уверенными, что эти проблемы не появятся в релизной версии платформы.
Мы стараемся рассматривать запросы таких партнеров по поводу найденных ошибок с высоким приоритетом.
Кстати, если кто-то из читателей этой статьи захочет принять участие в бета-тестировании платформы «1С:Предприятие», пишите на почту.
Планы
В планах переход на Continuous Delivery — практику, подразумевающую постоянную готовность основной сборки к релизу, чтобы сократить время от завершения разработки до релиза.Для этого мы хотим расширить тестовый охват и разработать функциональное и нагрузочное тестирование.
Теги: #1с #ERP-системы #программирование #тестирование для #1с:предприятие #Тестирование ИТ-систем #Анализ и проектирование систем #Управление разработкой
-
Рисунок 3 — След Теней
19 Oct, 24 -
Phdays Iii Ctf: Взгляд Изнутри (Часть 2)
19 Oct, 24 -
Системы Контроля Версий: Fossil, Часть I
19 Oct, 24