Я хочу рассказать о решении вопросов обеспечения качества программного продукта или, как это еще называют, Quality Assurance.
С чего все начиналось
Немного ретроспективы или с чего все начиналось.
- Раньше деревья были маленькие, и программные прикладные решения не очень сложные. И даже на 1С версии 7 некоторые профессионалы могли создавать полноценные решения в одиночку. Однако, бизнес не стоит на месте, он развивается. Вместе с ним развивается и платформа 1С. Сначала была 7.7, потом 8.0, 8.1, 8.2, 8.3, сейчас уже появилась 8.4. Одновременно происходит развитие прикладных решений. Если раньше для осуществления подобных задач было достаточно одного человека, то теперь это уже вопрос даже не команды, а нескольких подразделений или групп. В итоге актуально стоит вопрос тестирования. Изначально тестирование было ручное, оно занимало определенное разумное время, но чем дальше, тем все больше требовалось этого времени.
- У нас происходило то же самое – сначала был маленький продукт на 7-ке, потом, когда пришло время переходить на платформу 8.2 и далее на 8.3, возникла дилемма – создавать для учета свой продукт или нет. Мы поняли, что не эффективно выполнять эту задачу своими силами и приняли решение внедрять 1С:ERP, дорабатывая конфигурацию под свои потребности – так сейчас делает большинство разработчиков и владельцев бизнеса.
- Внедрять и дорабатывать мы начали где-то полтора года назад. Раньше программный продукт такой как УПП иногда можно было внедрить относительно быстро - чуть ли не за 1 месяц, то теперь внедрение и доработка решения подобного масштаба, как ERP, требовало от нас больших затрат и ресурсов.
Мы поняли, что тесты должны быть автоматизированы.
Около двух лет назад мы начали проводить обзор продуктов, на которых можно автоматизировать тестирование. Пробовали большое количество решений – смотрели, оценивали. У всех были плюсы и минусы. Что-то великолепно работало, но предназначалось только для web, что-то имело проблемы финансового плана – стоило дорого. Для нас было наиболее критичным, чтобы инструменты тестирования могли работать с 1С.
В итоге мы остановились на следующих инструментах, которые сейчас довольно успешно используем. Об их использовании я и расскажу по порядку чуть подробнее.
Сценарные тесты (UI)
Внедрение автоматизации тестирования – это довольно большой и сложный вопрос, поэтому внедряли мы постепенно. Начали мы со сценарных тестов или тестов, которые проверяют пользовательский интерфейс – под такими тестами мы подразумеваем проверку бизнес-процессов.
Как мы создаем сценарные тесты?
- Сначала мы должны формализовать бизнес-процесс, который необходимо проверить. Можно сказать, что, если вы описали бизнес-процесс – это уже 50% успеха. Для формализации бизнес-процессов очень удачно подходит нотация Business Process Model and Notation (BPMN). У нее очень много плюсов.
- При формировании сценарного теста обязательно необходимо использовать какие-то заготовки, готовые блоки – писать все время с нуля неэффективно.
- Обязательно слушаем, что говорят пользователи, и покрываем все проблемные места.
Используя BPMN, мы получаем ряд преимуществ.
- Первое – это разделение по ролям: на примере мы сразу видим, какие действия у нас выполняет покупатель, а какие – менеджер и логист.
- На схеме представлены основные действия, которые можно разбить на повторяющиеся блоки – появляется возможность создать небольшую библиотеку блоков-действий, из которых потом можно быстро собрать сценарий проверки нового бизнес-процесса.
- Эти блоки взаимодействуют между собой через параметры. Например, менеджер создал заказ и звонит кладовщику: «Отгрузи, пожалуйста, заказ номер такой-то», где номер заказа это параметр.
Создав такой набор блоков, вы можете дальше спокойно с ним работать как с конструктором.
Когда я сам попробовал так сделать, то был приятно удивлен – простой тест собирается буквально за несколько минут. Однако в рамках 1С:ERP тесты все-таки довольно сложные. Я общался с коллегами смежных языков программирования – у них таких сложностей нет. У них все тесты могут проходить за несколько минут: поместили изменение, прогнали тесты, и все готово. В 1С так не получается. В простом сценарном тесте может получиться порядка шестисот шагов, которые исполняются около 4-х минут. Если мы добавляем сюда разделение по ролям, то время еще больше увеличивается. Также на росте времени выполнения сказывается объем данных в базе. Поэтому не старайтесь протестировать все возможные варианты и комбинации действий, а выделяйте основные важные для бизнеса процессы, которые необходимо автоматизировать. Используйте в подходе к последовательному покрытию тестами принцип Парето - “ 20% дают нам 80% результата”.
«Менеджер сценарного теста»
Инструмент, который мы используем для создания сценарных UI тестов – это «Менеджер сценарного теста». Он позволяет выполнить довольно большой спектр задач:
- Запись действий, преобразование
- Удобный визуальный конструктор
- Управление проектами
- Создание параметризированных тестов
- Поддержка командной строки
- Формат отчетов Junit, Allure
По ссылке https://github.com/ivanov660/TestingTool-3 вы можете посмотреть и попробовать обработку в действии.
Рассматриваемый инструмент использует Automation API от 1С.
Одним из больших плюсов, которые предоставляет «Менеджер тестирования» – является то, что с его помощью вы можете проверить бизнес-процесс в разрезе разных пользователей. Система последовательно запускает несколько клиентских приложений:
- менеджера, который просит отгрузить заказ;
- бухгалтера, который оплачивает заказ;
- логиста, который отгружает и закрывает и т.д.
Таким образом, мы сразу проверяем как вопросы управления доступом, так и саму цепочку.
Проблем, с которыми мы столкнулись, было довольно много, но большинство из них решаемы или есть альтернативные варианты решения. К примеру, не всегда работает запись горячих кнопок, поэтому старайтесь выполнять действия с помощью мышки.
У сценарных тестов есть особенность – они технически сложные и длительные по времени выполнения, но зато имеют высокую ценность с точки зрения тестирования программного продукта.
Рассмотрим оптимизацию создания и выполнения сценарных тестов. Например, если вы сделали тест для бизнес-процесса «продажи с самовывозом», то делать тест для бизнес-процесса «продажи с отгрузкой» – необязательно. Достаточно написать один тест и пройти его. И второй тест вы можете начать с того момента, где происходит ответвление.
Еще на счет сценарных тестов хотел бы сказать, что подход, который я видел в сценарном тестировании, не совсем работает. Стандартно предполагается, что вы сначала разворачиваете базу, запускаете тесты, потом, если какой-то тест не прошел, нужно опять начинать все сначала. Это очень долго. Поэтому мы стараемся писать тесты так, чтобы они были повторяемы в одной и той же базе многократно. Запускаем один тест – он упал. Если необходимо, то удаляем данные и запускаем второй раз и т.д.
На слайде приведена схема, как мы разрабатываем сценарные тесты.
Юнит-тесты (проверка функций)
Следующий момент, на котором я остановлюсь – это юнит-тесты или функциональные тесты. Их мы используем для проверки функций.
Если сценарные тесты мог создавать аналитик или тестировщик (специалист не знакомый с программированием), то функциональные тесты должен делать разработчик. Но разработчики, особенно разработчики 1С – это относительно ленивый народ. Заставить их что-либо делать сверх того что они привыкли делать – тяжело. Также на этот процесс влияют особенности используемых в работе инструментов. Если для решения задачи им нужно 5 минут, а для создания теста – полчаса, то, скорее всего, тест они писать не будут. Это как на велосипеде: если вам дать велосипед с квадратными или треугольными колесами, вы его отставите в сторону. И даже если дать вам нормальный велосипед с круглыми колесами, а вы обычно ездите на машине, то вы все равно этот велосипед использовать не будете. Но ничего не стоит на месте и инструменты для тестирования развиваются, также меняется мировоззрение специалистов. А мы с вами можем активно способствовать этому процессу.
В качестве инструмента для создания юнит-тестов мы используем xUnitFor1C. Изначально он у нас не «поехал», пришлось его немного доработать совместно с авторами.
На слайде показан практический кейс, как создать простой серверный тест.
- Мы определяем, что хотим проверить – допустим, это функция создания коммерческого документа.
- Подготавливаем набор определенных данных, которые должны быть на входе этой функции – сохраняем этот набор в макет.
- На выходе этой функции мы должны получить эталонный документ – его ожидаемые данные также сохраняем в макет.
- Пишем тест, который загружает начальные данные, проверяет эту функцию и сравнивает сгенерированный документ с эталоном.
- Запускаем этот тест в фреймворке xUnitFor1C.
Плюс данного шаблона в том, что вы можете создать один тестовый случай и отдать его менее квалифицированному сотруднику или стажеру, который добьет вам другие начальные данные: с самовывозом, без самовывоза, в рублях, в евро и т.д. Таким образом, вы покроете определенную функциональность.
Еще один кейс для юнит-тестов – это проверка печатных форм. Здесь вообще все можно унифицировать довольно широко.
- Если мы хотим проверить какую-то печатную форму – то можно сохранить ее в макет и покрасить кисточкой то, что нужно проверить (или наоборот то, что не нужно сравнивать). И потом мы можем написать тест, который по аналогичному принципу сравнивает то, что выделено в макете, и то, что выводится в печатную форму.
- Этот тест можно еще более унифицировать, если использовать для определения правильных значений, например, RegExp и проверять по общему принципу, например: здесь должно быть заполнено, а здесь не должно; ИНН должен состоять из 10 или 12 цифр и т. д. В этом случае можно реализовать проверку вообще без начальных данных, сразу целой выборкой, потому что в тестировании важна не только проверка правильных значений, но еще и неправильных. Это немаловажный факт.
Если вы собираетесь создавать юнит-тесты для разработчиков, имеет смысл учитывать определенные кейсы:
- Клиентские тесты лучше делать сценарными.
- Используйте различные функции «1С:БСП» – это упростит вам жизнь.
На этой схеме вы можете увидеть, как мы создаем юнит-тесты.
Использование «роботов» в тестах
Самый интересный вид тестов, на мой взгляд – это так называемые интеллектуальные тесты.
По какому принципу они работают? Это, конечно, не нейронные сети. Использовать в тестировании нейронные сети сейчас звучит как что-то фантастическое, но, мы считаем, за этим направлением будущее. Тема очень интересная и в дальнейшем мы будем ее расширять и прорабатывать. Но пока что это достаточно сложно.
Я думаю, многие знают игры Quake, Far Cry и т.д. В них вся логика построена на принципе «конечных автоматов».
- Мы составляем «матрицу состояний» для действий, которые выполняют пользователи. Допустим, пользователь нажимает кнопку, вводит данные и т.д.
- Дальше мы «скармливаем» машине вектор разных входных значений, в том числе во времени.
Этот же подход можно использовать и в нагрузочном тестировании. В отличии от других подходов, где использовалось моделирование нагрузки на сервере, данный вариант дает меньшее искажение реальной картины происходящего. Мы на своем опыте сталкивались с тем, что визуально проведение документа может происходить 20-30 секунд, а APDEX при этом будет показывать, что проведение заняло 1-1,5 секунды – получается, что остальное время уходит на отображение обновления списков.
На слайде показана схема стенда, на котором мы проводили нагрузочное тестирование:
- Изначально система с пользователями находилась в состоянии покоя;
- Затем мы инициировали создание заказа от клиента;
- И потом по очереди прогонялась функциональность менеджера, кладовщика и т.д.
Может быть, это чем-то похоже на smoke-тесты.
Особенности организации процесса тестирования
Итак, мы научились создавать сценарные тесты, проверять пользовательский интерфейс, бизнес-процессы, функции. Возникает вопрос – как все это запускать и на чем смотреть? Инструментов множество:
- Сейчас мы используем Jenkins для создания и обновления сборок.
- А для запуска тестирования и просмотра отчетности по тестам мы используем конфигурацию «Тестирование 3.0».
Хочу обратить внимание, что:
- Изначально мы запускали юнит-тесты из одного каталога набором, но потом поняли, что так они выполняются слишком долго и не оптимально, поэтому разделили их по каталогам «Продажи», «Производство» и т.д. и запускаем параллельно.
- Сценарные тесты мы запускаем также параллельно, но по одному.
У внедрения процесса тестирования есть несколько особенностей:
- Конечно, хотелось бы получить все «из коробки». Хорошо, когда есть уже различные готовые системы – например, Elastic Search и т. д., но их использование повышает стоимость владения продуктом и требует более высокой квалификации сотрудников. Скажу из опыта – это все дается довольно тяжело, особенно, если у вас нагруженный рабочий процесс.
- Есть еще одна большая проблема, причем, не только среди сообщества 1С, но и среди других сообществ: этап тестирования практически все пытаются исключить или скрыть. На тесты обычно никто никогда не закладывает деньги. В итоге, когда бизнес сталкивается с неработающей функциональностью, он получает издержки.
- Но если мы автоматизируем тестирование, бизнес получит снижение издержек: уменьшение штрафных санкций за простои, неправильно распечатанные после апдейтов документы и т.д. Для некоторых бизнесов критично и недопустимо, что учетная система может какое-то время не работать. К сожалению, только на своем опыте люди понимают, что нужно что-то менять.
На рисунке представлена схема нашего процесса тестирования.
Какой принцип в разработке мы используем?
Сначала производится тестирование на уровне баз разработчиков. Этот процесс у нас отличается от других языков, где характерно, что прогон тестов происходит каждый раз при коммите, и это занимает пару минут.
Мы рекомендуем разработчику сначала запускать тесты (хотя бы только юнит-тесты) на своей базе, потому что сейчас процесс работы с хранилищем занимает много времени – один только захват происходит около двух минут. Сейчас 1С выпустила EDT, и я надеюсь, что мы сможем немного изменить этот процесс. Хотя бы 15-30 секунд на помещение – это было бы уже не так существенно.
- Дальше каждую ночь запускается ночной билд, по результатам которого мы понимаем, допустили мы ошибки или нет.
- Также есть база сборки, для которой мы запускаем тестирование каждый день и по требованию, потому что процесс сборки не быстрый – у разработчика уходит большое количество времени на то, чтобы поместить свои задачи в хранилище.
Конфигурация «Тестирование 3.0»
Загрузить и ознакомиться с документацией конфигурации можно с GitHub. Хранилище расположено по адресу: https://github.com/ivanov660/TestingTool-3
Плюс конфигурации «Тестирование 3.0» заключается в том, что мы фактически управляем процессом из одной точки. Причем все действия по управлению тестами мы можем делать в 1С без использования других инструментов.
Сама конфигурация довольно простая – в ней есть только основные объекты для хранения информации, а все остальные потребности интерфейса загружаются извне с помощью плагинов.
Например, есть плагин «Планировщик заданий», из которого можно запускать тесты параллельно – мы назвали его Jenkins Skin.
Есть плагин для просмотра результатов тестов – мы реализовали его по мотивам Яндекс Allure.
Есть история – можно посмотреть динамику изменения показателей относительно того, что было.
Заключение
Наша цель – снизить уровень вхождения в данный вопрос и получить от этого знания и обмен опытом.
Есть интересная идея – попробовать выложить все наши тесты для ERP в «облако» и сделать на базе этого коммьюнити.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.
