Автоматизация тестирования

Администрирование - Тестирование и исправление

63
Статья будет полезна всем, кто интересуется вопросами автоматизации тестирования. Владимир Крючков рассказывает о наработанных методиках, которые успешно использует в своей практике, приводит примеры инструментов для эффективной автоматизации тестирования, делится опытом создания сценарных, интеллектуальных и юнит-тестов, а также рассматривает проблемы их использования и предлагает пути решения.

Я хочу рассказать о решении вопросов обеспечения качества программного продукта или, как это еще называют, 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.

Приглашаем вас на новую конференцию INFOSTART EVENT 2018 Education.

63

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. Сурикат 182 04.10.18 12:37 Сейчас в теме
А подскажите, для Функциональных тестов вы каждый раз шаблон базы загружаете?
4. ivanov660 891 04.10.18 17:31 Сейчас в теме
(1) нет. мы не обновляем базу каждый раз. Поступаем двумя способами:
1. мы загружаем макеты с данными для серверных тестов в транзакции, после падения теста или его успеха данные и изменения откатываются.
2. для некоторых случаев мы загружаем на исходную базу макет некоторых настроек и цепочек (подготовленный набор незавершенных цепочек)
2. Kaval88 11 04.10.18 13:02 Сейчас в теме
Качественная статья, спасибо.
3. vlad.frost 178 04.10.18 14:44 Сейчас в теме
Причем все действия по управлению тестами мы можем делать в 1С без использования других инструментов.

Ого, круто! Запилили свой Jenkins и Allure!

А вы тестируете сложные интеграционные сценарии, например обмены РИБ?

Есть интересная идея – попробовать выложить все наши тесты для ERP в «облако» и сделать на базе этого коммьюнити.

Идея крутая. Подозреваю, что основная сложность здесь - это абстрагироваться от внутренней инфраструктуры - адресов серверов, папок, версий дистрибутивов, вот это вот всё.
5. ivanov660 891 04.10.18 17:45 Сейчас в теме
(3)
1. Мы формировали базу конфигурацию "Тестирование 3.0" с модульной архитектурой, т.е. внутри основной базис. Большая часть пользовательского функционала добавляется как плагины - обработка Allure Skin, Jenkins Skin и другие.

2. Мы предлагаем создать набор базовых блоков для типовой конфигураций ERP ( УТ/ КА внутри), а далее при применении тестов к доработанной конфигурации будет требоваться подправить функционал в некоторых местах (говорю по опыту). Мы выложили небольшой набор/библиотеку по следующему адресу: https://github.com/ivanov660/scripts-for-testing-1c ( тут есть готовые сценарии перемещения, закупки, продажи и определенный набор блоков)

3. Мы используем запуск сценариев по проверке бизнес цепочки между двумя/тремя базами (ERP, Логистическая база и Мобильное приложение). Поэтому не вижу проблем создать тест для процедуры с обменом (большая задержка будет в момент запуска обмена).
6. Artem-B 74 06.10.18 01:38 Сейчас в теме
Спасибо за статью. Возможно ли выполнить в вашем решении следующий довольно распространенный сценарный тест: пользователь создает документ - пользователь проводит документ - результат проведения по регистрам сравнивается с заранее подготовленным шаблоном проводок ? Не нашел подобную команду в списке команд менеджера сценарного тестирования.
7. ivanov660 891 06.10.18 23:24 Сейчас в теме
(6)
1. Можете сделать конечно.
а) Наиболее простой и эффективный способ: Для этого необходимо будет запустить менеджер в целевой базе, а потом выполнить произвольный код, в котором провести сравнение.
б) Можно конечно выполнить полностью интерактивно - использовать команду СравнитьДанные - когда вы формируете движения отчетом "Движения документа", а далее кликаете на поля и выполняете сравнение с заранее заданными данными. (видео примера тут: Сравнение данных элемента поля тестируемого клиента и значения параметра или предопределенного значения

Мы изначально в подобном ключе выполняли проверку корректности печатных форм, но потом перешли на юнит тест.

P.S. К сожалению, 1С пока не реализовала возможность передачи большого объема данных из таблицы, а также существуют проблемы при получении данных из табличных частей.


2. Однако, на мой взгляд необходимо разделять выполняемые задачи.
а) Менеджер использовать для тестирования работы интерфейса, интеграционного тестирования и бизнес процессов.
б) А проверку работы функций/данных выполнять юнит тестами - 1C for xUnit или новым воплощением АДД.

P.S. готовится в ближайшее время мощное обновление функционала менеджера сценарного теста - поддержка сторонних API: Automation UI (десктопные приложения) и Selenium (тестирование в браузере).
8. DrAku1a 1290 07.10.18 12:48 Сейчас в теме
Огромный плюс за иллюстрированность!
9. Makushimo 152 12.10.18 16:49 Сейчас в теме
Спасибо за статью
Есть пара вопросов
1. что такое Сервер управления тестами?
2. Что конкретно делает Jenkins?
3. Можно ли загрузить результаты прогона тестов Allure, которые получились после прогона на другом тестовом фреймворке?
4. Какими средствами вы делаете сборку? и что это вообще значит?
10. Makushimo 152 12.10.18 17:51 Сейчас в теме
Как можно связать тестовые сценарии с историями в Jira?
Заводить баги d Jira из Тестирование 3.0 на основе упавшего теста можно ли?
Реализована ли как то трассировка требований к функционалу компонента и тестовых сценариев? "Построение бизнес-модели" -это оно?
Оставьте свое сообщение