В этой статье пойдет речь о том, как мы автоматизируем процессы разработки и тестирования технологической платформы «1С:Предприятие 8». Платформа «1С:Предприятие 8» — набор инструментов для создания бизнес-приложений и среда их выполнения. Это большой (более десятка миллионов строк кода) проект на С++, Java и JavaScript. Над ним трудятся десятки программистов, одновременно разрабатывающие и поддерживающие до 10 различных версий продукта.
Платформа работает на различных версиях ОС и БД:
Поддерживает несколько видов клиентов:
Учитывая, что надо поддерживать целый ряд версий вышеперечисленных ОС, СУБД и браузеров, тестирование платформы становится нетривиальной задачей.
Цели, которые мы перед собой ставим:
Одновременная разработка нескольких версий платформы
Мы применяем в своей работе практику Continuous Integration (CI); слияние рабочих копий кода в общую основную ветвь происходит несколько раз в день, после слияния выполняется автосборка и автотестирование измененного проекта. В случае наличия проблем при сборке или тестировании изменённый код возвращается на доработку.
Процессы разработки одной версии платформы
Задачи, стоящие перед CI:
Автоматические сборки у нас проходят несколько раз в день. Полный цикл автоматического тестирования занимает около суток, что для некоторых задач, к сожалению, недопустимо долго (балансировка ресурсов тестирования ускоряет процесс при наличии свободных ресурсов – если таковые есть в данный момент). Чтобы нивелировать этот негативный эффект, мы развиваем «облегченную» версию тестов, которые должны прогоняться за час и затрагивают около 80% функциональности. Таким образом, общее понимание – насколько работоспособна сборка — мы можем получить значительно быстрее. Возможны случаи, когда и час не понадобится.
Сейчас при тестировании учитываются результаты предыдущих тестировочных циклов, и проблемные/новые/исправленные тесты запускаются с большим приоритетом, что позволяет увидеть прогресс изменений по наиболее изменяемому функционалу непосредственно в начале тестирования.
Для некоторого типа сборок принято правило «10 сбоев», когда серия тестов автоматически прерывается при достижении 10 сбоев в пределах одной серии, чтоб освободить ресурсы для тестирования других сборок/других версий и т.д.
В сборке и тестировании у нас участвует около 70 физических серверов и около 1500 виртуальных серверов.
Мы используем Jenkins в качестве системы непрерывной интеграции. В пиковые периоды он выполняет от 20 сборок платформы в день; на одну полную сборку уходит около 1.5 часов, на тестирование – от 1 часа. Сборка ведется параллельно по архитектурам (Windows, Linux, macOS), каждая сборка – в сотни потоков одновременно. Такой подход несколько лет назад позволил сократить время сборки одной версии платформы со всеми архитектурами с 8 часов до 80 минут, и мы не собираемся останавливаться на достигнутом.
Через веб-сервисы Jenkins интегрирован с нашим таск-трекером, «Базой Задач» (написанном на платформе «1С:Предприятие»), и в случае проблем автоматически заводит ошибки непосредственно в «Базе Задач», прикладывая ссылки на логи и артефакты тестирования. Также Jenkins подготавливает платформу к публикации, при необходимости фильтрует и разбирает дампы.
Также Jenkins управляет тестированием, позволяя реализовывать сколь угодно сложные сценарии на произвольных конфигурациях оборудования, в том числе на большом количестве виртуальных машин, а также делает дополнительную работу, например – доставку и установку платформы на 1500 серверов до 70 раз в день.
У JMeter есть очень ценное качество – у него низкие требования к оборудованию для эмуляции работы большого количества пользователей. Также JMeter позволяет генерировать смешанную нагрузку в одном тесте – HTTP, SOAP, JDBC, LDAP, SMTP, TCP.
В частности, мы используем JMeter для тестирования производительности кластера приложений и отдельных его компонент, а также для нагрузочного тестирования кластера приложений на большом количестве (до 10 000) пользователей. Для этого тестирования достаточно одного сервера БД, двух серверов 1С и одного сервера нагрузки.
У нас есть 4 стенда для тестирования, на которых тестируются одиночный кластер, кластер в отказоустойчивой и неотказоустойчивой конфигурациях; для тестирования этих конфигураций нам достаточно всего двух физических машин.
Графики производительности от JMeter
Для более сложного тестирования мы используем наш продукт Тест-центр (входит в состав Корпоративного Инструментального Пакета). Тест-Центр – это конфигурация на платформе «1С:Предприятие 8»; он позволяет описывать многопользовательские сценарии тестирования, автоматически запускать их и контролировать ход их выполнения. Мы запускаем Тест-центр на так называемых конвейерах; один конвейер состоит из 2 мощных физических серверов, на которых расположены виртуальные машины:
Мы приложили много усилий для повышения точности работы конвейера; сейчас у нас при прогоне тестов на одних и тех же версиях платформы и конфигурациях разброс результатов составляет менее 1.5%. На одном конвейере работают либо 100 очень быстрых клиентов (выполняющих операции без пауз), либо 1000 клиентов, приближенных к реальным пользователям (эмулирующих работу обычного человека, с паузами между действиями).
Конвейеры конструируют типовые варианты стендов:
Из конвейеров могут собираться 15 различных конфигураций рабочих площадок. Конфигурации различаются по составу серверов, отказоустойчивости. Сервера могут быть на Linux и Windows. Базы для тестирования (как и тестовые сценарии) подготовлены в двух вариантах:
Разделенные информационные базы (для тестирования работы в технологии 1cfresh) с конфигурациями:
В КОРП вариантах тестируются конфигурации:
Нагрузочные тесты могут задействовать: 1, 2, 4, 10 конвейеров.
Нагрузочные тесты есть в вариантах на 100, 200, 400, 3000 и 10000 пользователей.
В разных конфигурациях рабочих площадок количество серверов в кластере варьируется от 1 до 6.
Для запуска тестов на 10000 пользователей в одной базе используется два рабочих сервера приложений 1С. Каждая конфигурация кластера настраивается автоматически из сотни параметров в начале каждого теста. По сути можно считать, что стенд полностью готовится к работе автоматически, т.к.:
Скрипты настройки кластера, конфигурационных файлов, ОС, специальные обработки хранятся централизованно в Git и доставляются на стенды автоматически при наличии изменений.
Также у нас есть сценарии тестирования реструктуризации (обновления версии продукта, в ходе которого изменяется структура базы данных). Мы тестируем реструктуризацию на этих же стендах. После выполнения теста проверяется конечный результат — данные в базе должны быть обновлены корректно, и структура БД должна соответствовать новой версии. Тестируется как старый, так и новый механизм реструктуризации.
В ходе проведения нагрузочных тестов мы автоматически собираем и анализируем:
По всем данным автоматически формируются отчеты (различные в зависимости от типов тестов), которые рассылаются ответственным. Все данные сохраняются и агрегируются в специальной базе со статистикой и результатами тестов.
Экран Тест-центра
Еще мы проводим нагрузочное тестирование работы 10 000 пользователей в конфигурации «1С:ERP Управление предприятием 2» на отказоустойчивом кластере с моделированием отказов оборудования, отказов сети, нехваткой памяти, ресурсов ЦПУ и места на диске. Это большой тестовый сценарий, в котором поочередно на протяжении всего теста моделируется зависание серверных процессов 1С, часть процессов «убивается» утилитой taskkill, отключается и восстанавливается сеть и т.д. В рамках тестирования прогоняются пользовательские сценарии работы в разных подсистемах – склад, закупки, продажи, взаиморасчеты и т.д. В нагрузочном тесте ERP проводится около 400 ключевых операций, тест идет несколько часов.
Поверх описанных систем работает наш внутренний инструмент – «Сравнение Производительности Конфигураций» (СПК), позволяющий сравнивать производительность:
В системе «Сравнение Производительности Конфигураций» собираются все те же параметры, которые собираются в ходе обычных нагрузочных тестов. Система позволяет автоматически выявить появление ошибки, изменение нагрузки на серверах, изменение длительности запросов (или появление запросов, которых раньше не было).
Мы анализируем как ухудшение показателей, так и улучшение, что может быть симптомом какой-либо проблемы.
Система может использоваться для сравнения
В результате мы получаем отчеты о пройденных нагрузочных тестах, с детализацией информации и сравнением производительности, нагрузки на оборудование; в отчетах содержится время выполнения запросов к СУБД, факты возникновения исключений и т.д.
Под сравнением производительности подразумевается измерение общей производительности конфигураций, среднего времени работы и среднего APDEX по каждой ключевой операции.
Все вышеперечисленные инструменты эмулируют работу пользователей, вызывая соответствующие методы встроенных объектов тестируемых конфигураций, делая вызовы web- и HTTP-сервисов и т.п. Но также крайне важно тестировать именно то, что реально видит пользователь, особенно пользователь, работающий через веб-клиент (где довольно существенное время может занять отрисовка интерфейса браузером). Мы сталкивались с ситуацией, когда производительность с точки зрения автоматических тестов при переходе на новую версию не менялась, но когда мы сажали человека с секундомером, то он получал одни числа на старой версии, и совершенно другие – на новой. Связано это, в частности, со временем отрисовки графического интерфейса, которое в новой версии по какой-то причине могло поменяться.
Мы написали свой инструмент, позволяющий делать визуальное тестирование практически любого приложения. Инструмент записывает действия пользователя, запустившего приложение, в файл-сценарий. Инструмент также записывает изображение рабочей области экрана. При контроле новых версий клиента сценарии проигрываются без пользовательского участия. При проигрывании сценария инструмент, прежде чем сэмулировать нажатие клавиш или кнопок мыши, ожидает появления такой же картинки экрана (с точностью до пикселя), какая была в записанном сценарии.
Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд, результаты пишет в лог для дальнейшего автоматического сравнения. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения сценария. Это тестирование, помимо замера производительности, также позволяет нам быть уверенными, что в новой версии платформы пользователь увидит в тонком клиенте и в браузере те же экраны, что и на предыдущей версии приложения.
Пример запуска сценария по вводу заказа в конфигурации «Управление Нашей Фирмой» — заказ вводится 5 раз; вот реальная скорость работы платформы «1С:Предприятие», если пользователь мгновенно реагирует на доступность интерфейса:
Мы также активно развиваем функциональное тестирование. Тестируем комбинации основных версий ОС и баз данных, на каждую такую комбинацию у нас есть свой комплект виртуальных машин, весь комплект комбинаций образует один конвейер; автоматизировано добавление новых комбинаций ОС и БД в этот конвейер. Каждый функциональный тест превращается в набор задач, исполняющихся на всех возможных комбинациях; задачи выполняются первыми свободными стендами. Тестируются Конфигуратор (среда разработки прикладных решений 1С), функции встроенного языка, язык запросов и т.д.
При тестировании Конфигуратора мы проверяем большинство команд, доступных в командной строке Конфигуратора. Помимо этого у нас есть специальная библиотека (наружу мы ее не поставляем), позволяющая тестировать внутреннюю логику работы Конфигуратора, доступную только через пользовательский интерфейс, не прибегая к непосредственному UI-тестированию. Таким образом, тестируется большинство функций по работе с расширениями конфигурации, функционал сравнения/объединения и другой функционал Конфигуратора.
Для целей тестирования в этом режиме доступно написание скриптов на языке 1С. В рамках скрипта доступны специальные объекты для целей тестирования. Запуск конфигуратора в этом режиме может совмещаться в одном тесте с запуском клиентского приложения. Это позволяет использовать этот режим не только как средство тестирования конфигуратора, но и как способ настройки тестового окружения.
Есть ряд наших внутренних инструментов, написанных на платформе «1С:Предприятие», которые мы используем в нашей ежедневной работе. Они работают на самых свежих сборках платформы. Ниже мы расскажем о двух из них – «Базе задач» и «Отчетах сотрудников».
Наш внутренний таск-трекер, «База задач» — конфигурация, написанная на платформе «1С:Предприятие». Это 21 самостоятельная база (часть баз – рабочие, часть — тестовые) на разных версиях платформы, с разными ОС и СУБД, базы синхронизируются через платформенный механизм обмена данными; версии платформы обновляются ежедневно, на некоторых серверах ставятся экспериментальные версии платформы с отдельными новыми фичами. Закоммиченную новую функциональность платформы можно тестировать на «Базе Задач» уже на следующий день. Разные экземпляры баз работают с разным серверным окружением (ОС, СУБД) и с разными версиями платформы, а пользователи еще и входят с разных клиентов (тонкий клиент, мобильный клиент) и через веб-клиент с разных браузеров. Таким образом, осуществляется тестирование разных версий платформы в разном окружении.
«Отчеты сотрудников» — это тайм-трекер для учета рабочего времени, который используют сотрудники отдела разработки платформы «1С:Предприятие». Он работает на самой последней сборке платформы.
Типовое решение «1С:Документооборот», которым пользуются все сотрудники нашей фирмы, мы также используем с новыми, еще не выпущенными версиями платформы.
Наряду с автоматическими визуальными тестами популярных прикладных решений («Бухгалтерия Предприятия», «Управление Нашей Фирмой», «Зарплата и Управление Персоналом» и т.п.) мы проводим ручные тесты: сценарные, визуальные, ручную отработку по тест-плану основных кейсов. После достижения определенного уровня качества платформы мы просим разработчиков прикладных конфигураций перейти на разработку на новой версии платформы и протестировать свои продукты на готовящейся к выпуску версии.
Некоторые наши партнеры проявляют заинтересованность в использовании ранних, еще не выпущенных версий платформы «1С:Предприятие». Такие партнеры подписывают с фирмой «1С» NDA, получают доступ к сборкам платформы до выхода тестовой версии и имеют возможность использовать самую новую версию платформы в реальных условиях. Это позволяет партнерам на ранней стадии обнаружить проблемы в платформе и быть уверенными, что в релизной версии платформы этих проблем уже не будет. Обращения от таких партнеров по поводу найденных ошибок мы стараемся рассматривать с высоким приоритетом. Кстати, если кто-то из читателей этой статьи захочет принять участие в бета-тестировании платформы «1С:Предприятие» — пишите на CorpTechSupport@1c.ru.
В планах – переход на Continuous Delivery, на практику, предполагающую постоянную готовность основной сборки к выпуску, чтобы сократить сроки от окончания разработки до выпуска. Для достижения этого мы хотим расширять покрытие тестами, развивать функциональное и нагрузочное тестирование.
Платформа работает на различных версиях ОС и БД:
- ОС: Windows, Linux, macOS
- СУБД: MS SQL, PostgreSQL, IBM DB2, Oracle, файловая СУБД собственной разработки
- Мобильные ОС: Android, iOS, Windows
Поддерживает несколько видов клиентов:
- Тонкий клиент
- Толстый клиент
- Веб-клиент (Internet Explorer, Microsoft Edge, Chrome, Firefox, Safari)
- Мобильный клиент
Учитывая, что надо поддерживать целый ряд версий вышеперечисленных ОС, СУБД и браузеров, тестирование платформы становится нетривиальной задачей.
Общие задачи автоматизации
Цели, которые мы перед собой ставим:
- Максимально автоматизировать и ускорять рутинные задачи разработки и тестирования
- Непрерывное тестирование с минимальными усилиями на проведение теста
- Добавлять в версию продукта только качественный новый код
- Не ломать старую функциональность
- Приблизить число существенных дефектов в выпускаемой платформе к нулю
- Обнаруживать проблемы на ранних стадиях, чтобы снизить до минимума затраты на расследование и исправление
Одновременная разработка нескольких версий платформы
Мы применяем в своей работе практику Continuous Integration (CI); слияние рабочих копий кода в общую основную ветвь происходит несколько раз в день, после слияния выполняется автосборка и автотестирование измененного проекта. В случае наличия проблем при сборке или тестировании изменённый код возвращается на доработку.
Процессы разработки одной версии платформы
Задачи, стоящие перед CI:
- Сборка
- Серия сборок различного типа и последующее тестирование изменяемых версий, как часть непрерывного цикла. Для ускорения расследования изолированных изменений в результатах тестов мы используем инкрементальную компиляцию – компилируется только то, что изменилось и прямые зависимости. Для полного цикла тестирования сборки собираются полностью. Необходимость и последовательность дополнительных сборок определяется результатами тестирования, предварительный анализ которых автоматизирован.
- Проверка «в стороне» существенных изменений (интеграционные сборки). В случае если инженер считает изменения существенными, он вначале вливает их в отдельную ветку, собирает ее и прогоняет все тесты. При успешном прохождении всех тестов изменения вносятся в основную ветку.
- Максимально быстрое обнаружение ошибок, по возможности в автоматическом режиме
- Автоматизация рутинных действий (анализ дампов, миграция изменений между ветками, регистрация ошибок)
- Многоуровневое тестирование
- Регрессионное
- Юнит-тесты
- Интеграционное тестирование
- Нагрузочные тесты
- Визуальные тесты
- Тесты обратной совместимости
- Сценарное тестирование
- Прогрессионное
- В основном функциональное
- Приемочное тестирование
- Тестирование прогресса и изменений
- сюда же отнесем и ручное тестирование
Автоматические сборки у нас проходят несколько раз в день. Полный цикл автоматического тестирования занимает около суток, что для некоторых задач, к сожалению, недопустимо долго (балансировка ресурсов тестирования ускоряет процесс при наличии свободных ресурсов – если таковые есть в данный момент). Чтобы нивелировать этот негативный эффект, мы развиваем «облегченную» версию тестов, которые должны прогоняться за час и затрагивают около 80% функциональности. Таким образом, общее понимание – насколько работоспособна сборка — мы можем получить значительно быстрее. Возможны случаи, когда и час не понадобится.
Сейчас при тестировании учитываются результаты предыдущих тестировочных циклов, и проблемные/новые/исправленные тесты запускаются с большим приоритетом, что позволяет увидеть прогресс изменений по наиболее изменяемому функционалу непосредственно в начале тестирования.
Для некоторого типа сборок принято правило «10 сбоев», когда серия тестов автоматически прерывается при достижении 10 сбоев в пределах одной серии, чтоб освободить ресурсы для тестирования других сборок/других версий и т.д.
В сборке и тестировании у нас участвует около 70 физических серверов и около 1500 виртуальных серверов.
Инструменты
Jenkins
Мы используем Jenkins в качестве системы непрерывной интеграции. В пиковые периоды он выполняет от 20 сборок платформы в день; на одну полную сборку уходит около 1.5 часов, на тестирование – от 1 часа. Сборка ведется параллельно по архитектурам (Windows, Linux, macOS), каждая сборка – в сотни потоков одновременно. Такой подход несколько лет назад позволил сократить время сборки одной версии платформы со всеми архитектурами с 8 часов до 80 минут, и мы не собираемся останавливаться на достигнутом.
Через веб-сервисы Jenkins интегрирован с нашим таск-трекером, «Базой Задач» (написанном на платформе «1С:Предприятие»), и в случае проблем автоматически заводит ошибки непосредственно в «Базе Задач», прикладывая ссылки на логи и артефакты тестирования. Также Jenkins подготавливает платформу к публикации, при необходимости фильтрует и разбирает дампы.
Также Jenkins управляет тестированием, позволяя реализовывать сколь угодно сложные сценарии на произвольных конфигурациях оборудования, в том числе на большом количестве виртуальных машин, а также делает дополнительную работу, например – доставку и установку платформы на 1500 серверов до 70 раз в день.
Apache JMeter
У JMeter есть очень ценное качество – у него низкие требования к оборудованию для эмуляции работы большого количества пользователей. Также JMeter позволяет генерировать смешанную нагрузку в одном тесте – HTTP, SOAP, JDBC, LDAP, SMTP, TCP.
В частности, мы используем JMeter для тестирования производительности кластера приложений и отдельных его компонент, а также для нагрузочного тестирования кластера приложений на большом количестве (до 10 000) пользователей. Для этого тестирования достаточно одного сервера БД, двух серверов 1С и одного сервера нагрузки.
У нас есть 4 стенда для тестирования, на которых тестируются одиночный кластер, кластер в отказоустойчивой и неотказоустойчивой конфигурациях; для тестирования этих конфигураций нам достаточно всего двух физических машин.
Графики производительности от JMeter
Тест-центр
Для более сложного тестирования мы используем наш продукт Тест-центр (входит в состав Корпоративного Инструментального Пакета). Тест-Центр – это конфигурация на платформе «1С:Предприятие 8»; он позволяет описывать многопользовательские сценарии тестирования, автоматически запускать их и контролировать ход их выполнения. Мы запускаем Тест-центр на так называемых конвейерах; один конвейер состоит из 2 мощных физических серверов, на которых расположены виртуальные машины:
- 1 сервер приложений 1С
- 1 сервер БД
- 1 сервер лицензирования
- 40 серверов с клиентскими сеансами
Мы приложили много усилий для повышения точности работы конвейера; сейчас у нас при прогоне тестов на одних и тех же версиях платформы и конфигурациях разброс результатов составляет менее 1.5%. На одном конвейере работают либо 100 очень быстрых клиентов (выполняющих операции без пауз), либо 1000 клиентов, приближенных к реальным пользователям (эмулирующих работу обычного человека, с паузами между действиями).
Конвейеры конструируют типовые варианты стендов:
- малые
- средние
- большие
Из конвейеров могут собираться 15 различных конфигураций рабочих площадок. Конфигурации различаются по составу серверов, отказоустойчивости. Сервера могут быть на Linux и Windows. Базы для тестирования (как и тестовые сценарии) подготовлены в двух вариантах:
- облачном, для технологии 1cfresh (база с большим количеством сравнительно небольших областей данных)
- КОРП, для крупных внедрений (база большого размера)
Разделенные информационные базы (для тестирования работы в технологии 1cfresh) с конфигурациями:
- 1С:Бухгалтерия
- Управление нашей фирмой
- Зарплата и управление персоналом
В КОРП вариантах тестируются конфигурации:
- Зарплата и Управление Персоналом
- 1С:ERP Управление предприятием 2
Нагрузочные тесты могут задействовать: 1, 2, 4, 10 конвейеров.
Нагрузочные тесты есть в вариантах на 100, 200, 400, 3000 и 10000 пользователей.
В разных конфигурациях рабочих площадок количество серверов в кластере варьируется от 1 до 6.
Для запуска тестов на 10000 пользователей в одной базе используется два рабочих сервера приложений 1С. Каждая конфигурация кластера настраивается автоматически из сотни параметров в начале каждого теста. По сути можно считать, что стенд полностью готовится к работе автоматически, т.к.:
- доставляется платформа
- доставляются скрипты
- настраивается кластер
- загружается база данных
- настраиваются конфигурационные файлы (по заданным параметрам)
- готовятся публикации информационных баз
Скрипты настройки кластера, конфигурационных файлов, ОС, специальные обработки хранятся централизованно в Git и доставляются на стенды автоматически при наличии изменений.
Также у нас есть сценарии тестирования реструктуризации (обновления версии продукта, в ходе которого изменяется структура базы данных). Мы тестируем реструктуризацию на этих же стендах. После выполнения теста проверяется конечный результат — данные в базе должны быть обновлены корректно, и структура БД должна соответствовать новой версии. Тестируется как старый, так и новый механизм реструктуризации.
В ходе проведения нагрузочных тестов мы автоматически собираем и анализируем:
- все ошибки по данным Тест-Центра
- исключения из технологического журнала платформы
- все запросы из технологического журнала платформы
- все ошибки из журнала регистрации
- все замеры выполненных операций с технологической информацией о их выполнении
- все данные по загруженности оборудования
По всем данным автоматически формируются отчеты (различные в зависимости от типов тестов), которые рассылаются ответственным. Все данные сохраняются и агрегируются в специальной базе со статистикой и результатами тестов.
Экран Тест-центра
Еще мы проводим нагрузочное тестирование работы 10 000 пользователей в конфигурации «1С:ERP Управление предприятием 2» на отказоустойчивом кластере с моделированием отказов оборудования, отказов сети, нехваткой памяти, ресурсов ЦПУ и места на диске. Это большой тестовый сценарий, в котором поочередно на протяжении всего теста моделируется зависание серверных процессов 1С, часть процессов «убивается» утилитой taskkill, отключается и восстанавливается сеть и т.д. В рамках тестирования прогоняются пользовательские сценарии работы в разных подсистемах – склад, закупки, продажи, взаиморасчеты и т.д. В нагрузочном тесте ERP проводится около 400 ключевых операций, тест идет несколько часов.
Один из сценариев тестирования ERP (выполняющийся параллельно с другими сценариями)
Сравнение Производительности Конфигураций
Поверх описанных систем работает наш внутренний инструмент – «Сравнение Производительности Конфигураций» (СПК), позволяющий сравнивать производительность:
- разных версий одной конфигурации на одинаковой платформе
- двух версий платформы при работе одной и той же конфигурации
- разных версий БД/ОС с одной и той же платформой/конфигурацией
В системе «Сравнение Производительности Конфигураций» собираются все те же параметры, которые собираются в ходе обычных нагрузочных тестов. Система позволяет автоматически выявить появление ошибки, изменение нагрузки на серверах, изменение длительности запросов (или появление запросов, которых раньше не было).
Мы анализируем как ухудшение показателей, так и улучшение, что может быть симптомом какой-либо проблемы.
Система может использоваться для сравнения
- версий конфигураций,
- версий платформы,
- версий СУБД,
- каких-либо настроек
В результате мы получаем отчеты о пройденных нагрузочных тестах, с детализацией информации и сравнением производительности, нагрузки на оборудование; в отчетах содержится время выполнения запросов к СУБД, факты возникновения исключений и т.д.
Под сравнением производительности подразумевается измерение общей производительности конфигураций, среднего времени работы и среднего APDEX по каждой ключевой операции.
Визуальное тестирование
Все вышеперечисленные инструменты эмулируют работу пользователей, вызывая соответствующие методы встроенных объектов тестируемых конфигураций, делая вызовы web- и HTTP-сервисов и т.п. Но также крайне важно тестировать именно то, что реально видит пользователь, особенно пользователь, работающий через веб-клиент (где довольно существенное время может занять отрисовка интерфейса браузером). Мы сталкивались с ситуацией, когда производительность с точки зрения автоматических тестов при переходе на новую версию не менялась, но когда мы сажали человека с секундомером, то он получал одни числа на старой версии, и совершенно другие – на новой. Связано это, в частности, со временем отрисовки графического интерфейса, которое в новой версии по какой-то причине могло поменяться.
Мы написали свой инструмент, позволяющий делать визуальное тестирование практически любого приложения. Инструмент записывает действия пользователя, запустившего приложение, в файл-сценарий. Инструмент также записывает изображение рабочей области экрана. При контроле новых версий клиента сценарии проигрываются без пользовательского участия. При проигрывании сценария инструмент, прежде чем сэмулировать нажатие клавиш или кнопок мыши, ожидает появления такой же картинки экрана (с точностью до пикселя), какая была в записанном сценарии.
Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд, результаты пишет в лог для дальнейшего автоматического сравнения. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения сценария. Это тестирование, помимо замера производительности, также позволяет нам быть уверенными, что в новой версии платформы пользователь увидит в тонком клиенте и в браузере те же экраны, что и на предыдущей версии приложения.
Пример запуска сценария по вводу заказа в конфигурации «Управление Нашей Фирмой» — заказ вводится 5 раз; вот реальная скорость работы платформы «1С:Предприятие», если пользователь мгновенно реагирует на доступность интерфейса:
Функциональное тестирование
Мы также активно развиваем функциональное тестирование. Тестируем комбинации основных версий ОС и баз данных, на каждую такую комбинацию у нас есть свой комплект виртуальных машин, весь комплект комбинаций образует один конвейер; автоматизировано добавление новых комбинаций ОС и БД в этот конвейер. Каждый функциональный тест превращается в набор задач, исполняющихся на всех возможных комбинациях; задачи выполняются первыми свободными стендами. Тестируются Конфигуратор (среда разработки прикладных решений 1С), функции встроенного языка, язык запросов и т.д.
При тестировании Конфигуратора мы проверяем большинство команд, доступных в командной строке Конфигуратора. Помимо этого у нас есть специальная библиотека (наружу мы ее не поставляем), позволяющая тестировать внутреннюю логику работы Конфигуратора, доступную только через пользовательский интерфейс, не прибегая к непосредственному UI-тестированию. Таким образом, тестируется большинство функций по работе с расширениями конфигурации, функционал сравнения/объединения и другой функционал Конфигуратора.
Для целей тестирования в этом режиме доступно написание скриптов на языке 1С. В рамках скрипта доступны специальные объекты для целей тестирования. Запуск конфигуратора в этом режиме может совмещаться в одном тесте с запуском клиентского приложения. Это позволяет использовать этот режим не только как средство тестирования конфигуратора, но и как способ настройки тестового окружения.
Eating your own dogfood
Есть ряд наших внутренних инструментов, написанных на платформе «1С:Предприятие», которые мы используем в нашей ежедневной работе. Они работают на самых свежих сборках платформы. Ниже мы расскажем о двух из них – «Базе задач» и «Отчетах сотрудников».
База задач
Наш внутренний таск-трекер, «База задач» — конфигурация, написанная на платформе «1С:Предприятие». Это 21 самостоятельная база (часть баз – рабочие, часть — тестовые) на разных версиях платформы, с разными ОС и СУБД, базы синхронизируются через платформенный механизм обмена данными; версии платформы обновляются ежедневно, на некоторых серверах ставятся экспериментальные версии платформы с отдельными новыми фичами. Закоммиченную новую функциональность платформы можно тестировать на «Базе Задач» уже на следующий день. Разные экземпляры баз работают с разным серверным окружением (ОС, СУБД) и с разными версиями платформы, а пользователи еще и входят с разных клиентов (тонкий клиент, мобильный клиент) и через веб-клиент с разных браузеров. Таким образом, осуществляется тестирование разных версий платформы в разном окружении.
Отчеты сотрудников
«Отчеты сотрудников» — это тайм-трекер для учета рабочего времени, который используют сотрудники отдела разработки платформы «1С:Предприятие». Он работает на самой последней сборке платформы.
«1С:Документооборот»
Типовое решение «1С:Документооборот», которым пользуются все сотрудники нашей фирмы, мы также используем с новыми, еще не выпущенными версиями платформы.
Тесты платформы в прикладных решениях
Наряду с автоматическими визуальными тестами популярных прикладных решений («Бухгалтерия Предприятия», «Управление Нашей Фирмой», «Зарплата и Управление Персоналом» и т.п.) мы проводим ручные тесты: сценарные, визуальные, ручную отработку по тест-плану основных кейсов. После достижения определенного уровня качества платформы мы просим разработчиков прикладных конфигураций перейти на разработку на новой версии платформы и протестировать свои продукты на готовящейся к выпуску версии.
Бета-тестирование платформы партнерами
Некоторые наши партнеры проявляют заинтересованность в использовании ранних, еще не выпущенных версий платформы «1С:Предприятие». Такие партнеры подписывают с фирмой «1С» NDA, получают доступ к сборкам платформы до выхода тестовой версии и имеют возможность использовать самую новую версию платформы в реальных условиях. Это позволяет партнерам на ранней стадии обнаружить проблемы в платформе и быть уверенными, что в релизной версии платформы этих проблем уже не будет. Обращения от таких партнеров по поводу найденных ошибок мы стараемся рассматривать с высоким приоритетом. Кстати, если кто-то из читателей этой статьи захочет принять участие в бета-тестировании платформы «1С:Предприятие» — пишите на CorpTechSupport@1c.ru.
Планы
В планах – переход на Continuous Delivery, на практику, предполагающую постоянную готовность основной сборки к выпуску, чтобы сократить сроки от окончания разработки до выпуска. Для достижения этого мы хотим расширять покрытие тестами, развивать функциональное и нагрузочное тестирование.
