Ранее мы уже писали как устроено тестирование КОМПАС-3D и про автоматизацию тестирования интерфейса КОМПАС-3D, сегодня расскажем про тестирование BIM-системы Renga.
Многие компании в процессе разработки программного обеспечения сталкиваются с проблемой появления регрессионных ошибок. И мы, к сожалению, не были исключением. В этой статье я бы хотела рассказать, как данная проблема проявилась у нас и какие пути решения мы нашли. Но сначала стоит пояснить, какую систему мы разрабатываем и как в нашей компании устроен процесс тестирования.
Что такое Renga
Renga Architecture — архитектурно-строительная BIM-система, разработанная Renga Software (совместное предприятие компаний АСКОН и 1С), для создания внешнего облика здания, информационной модели, быстрой компоновки чертежей. Ее пользователями являются архитекторы, проектировщики и конструкторы.
Renga Structure — cистема для проектирования конструктивной части зданий/сооружений. Программа для инженеров-конструкторов и проектировщиков по созданию информационной модели здания или сооружения и получению чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Renga предназначено для проектирования по технологии BIM. Высокая производительность систем позволяет работать с большими проектами без видимого снижения качества работы с 3D-моделью:
Объектное проектирование
Создание в Renga 3D-модели здания/сооружения инструментами объектного проектирования (стена, колонна, окно и т.д.)
Коллективная работа
Обмен хранение и управление данными осуществляется с помощью BIM-Server Pilot
Взаимодействие со сметными системами
Интеграция Renga по средством API со сметными системами 1С-смета и ABC-смета для взаимодействия проектного и сметного отделов.
Обмен данными
Renga позволяет обмениваться данными с другими системами через различные форматы (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo и .csv)
Автоматизация получения спецификаций и ведомостей
В Renga реализована функция получения отчетов для формирования спецификаций, ведомостей и экспликаций.
Автоматизация получения чертежей
По данным 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
Renga содержит множество инструментов, необходимых для того, чтобы создать архитектурную модель здания, спроектировать конструктивную часть, а также получить чертежи и спецификации.
Разумеется, мы тестируем всю функциональность системы. При тестировании мы должны учитывать, что пользователь может работать с моделью как в 3D, так и в 2D, а все сущности проекта связаны между собой. Сначала тестировщик проверяет работу функциональности вручную, идет проверка на соответствие требованиям. На этом этапе находятся ошибки, которые в дальнейшем разработчики будут исправлять. После ручного тестирования и исправления ошибок мы переходим к написанию интеграционных тестов, покрывая функциональность автотестами. Далее будет подробнее описан процесс тестирования, и как мы к нему пришли.
Ручное тестирование
Мы много времени тестируем вручную. Чтобы проверить работу нового объекта, например, стены, нужно проконтролировать:
- Построение стены в 3D и 2D.
- Редактирование стены за характерные точки, изменение её свойств и параметров.
- Поведение стены при пересечении с другими объектами (например, перекрытия, колонны и балки подрезают стену).
- Оформление чертежа со стенами.
- Правильность вывода расчетных характеристик стены (длины, площади, объёма и т.д.).
- Применение и отображение материалов стен.
- Работу стен при вставке оконных и дверных проёмов.
- Армирование стен: параметрическое армирование, раскладка сеток и каркасов в стенах.
- Локализацию параметров стены.
Это далеко не полный список того, что нужно проверять при добавлении нового объекта. А теперь представьте, каково количество этих объектов и связей!
В процессе ручного тестирования находятся ошибки, которые сложно воспроизвести, или они проявляются при определённом состоянии системы. Думаю, что ошибками в пользовательском интерфейсе никого не удивишь, а перечисленные ниже ошибки весьма интересны:
- “Некорректное отображение перил на дуговых лестницах малого радиуса”. Вот так данная ошибка выглядит в приложении:
- Перила “выстреливают” вверх вместо того, чтобы расположиться на лестнице небольшого радиуса.
- «Меняются местами кнопки на панели инструментов». Мы около месяца пытались поймать, в каких случаях кнопки меняются местами, так как в разных случаях это происходило по-разному.
В результате были выявлены весьма необычные шаги воспроизведения: нужно вызвать контекстное меню на 3D виде, затем прокликать несколько кнопок на панели инструментов левой кнопкой мыши, уйти и вернуться в текущую вкладку с панелью инструментов и… кнопки меняются местами! Ошибка начала воспроизводиться стабильно по описанным шагам и была быстро устранена. Больше времени ушло на то, чтобы научиться ее воспроизводить.
Автоматизированное тестирование
Разработка нашей BIM-системы была начата 6 лет назад. В самом начале разработки приложение тестировали вручную и при помощи unit-тестов. Весь функционал имел тестовое покрытие модульными тестами, но, несмотря на это, мы стали замечать, что ломаем уже сделанное ранее. Проблема заключалась в том, что модули работали в отдельности, но их интеграция приводила к ошибкам. Проблема нарастала, и было принято решение добавлять к unit-тестам интеграционное тестирование для проверки совместной работы всех модулей системы.
Поиск готовых решений
Для создания интерфейса мы используем QT-библиотеку, поэтому при поиске готовых продуктов для написания интеграционных тестов мы выбрали те, что могли работать с данной библиотекой. В качестве возможных решений мы рассматривали программы TestComplete и Squish, однако версии этих продуктов на тот момент нас не устроили: в Renga используются элементы управления, которые данные продукты не могли определить и работать с ними. А без них использовать данные продукты автоматизации было нецелесообразно.
Собственный фреймворк
Мы решили написать свой фреймворк, который будет повторять действия пользователя, работать с нужными нам элементами управления и покрывать большинство необходимых проверок. Разработка данного фреймворка началась еще в далеком 2012 году, и первоначально приложение выглядело следующим образом:
В процессе создания нового функционала в Renga дорабатывается и утилита. То есть, фактически, мы разрабатываем два приложения одновременно: Renga и фреймворк для тестирования.
Принцип работы фреймворка
Принцип заключается в записи и последующем проигрывании сценария, сравнении эталонных и результирующих снимков системы. Снимки системы описываются xml-файлами, которые создаются в момент записи и проигрывания теста. Такие xml-файлы в тесте бывают эталонными и результирующими. При записи теста генерируется набор эталонных xml-файлов фиксированного состояния системы, при проигрывании создается результирующий набор файлов. Существуют следующие виды xml-файлов, которые отвечают за разную функциональность приложения:
- Gui shots — логирование GUI приложения
- Model shots — модельные данные
- Sheets shots — данные и отрисовка чертежей
- Aux shots — положение характерных точек объекта и дополнительной геометрии
- Screen shots — снимок в формате png, который не сравнивается автоматически, а лишь используется для визуального сравнения
- Drawer shots — отрисовка объектов
- ReportCSV shots — экспорт данных в формат CSV
- Dxf shots — экспортимпорт данных в формат Dxf
- Xps shots — печать в xps
- API shots — тестирование API
- Table shots — отрисовка и данные таблиц
- Specification shots — данные спецификаций
- Specification view shots — отрисовка спецификаций
Как было описано выше, утилита дорабатывается вместе с Renga, в ней появляются новые типы снимков системы. Например, только при подготовке к последнему релизу для тестирования спецификаций в утилите добавились Specification shots и Specification view shots. А также, для удобства поиска определенных тестов, недавно была реализована система фильтрации при помощи скриптов на python.
Сейчас с помощью фреймворка можно проверить: отрисовку объектов, печать чертежей, экспорт и импорт объектов/чертежей в различные форматы, создание и редактирование объектов, изменение параметров и пользовательских свойств объекта, данные и отрисовку таблиц/спецификаций и т.д.
На текущий момент времени фреймворк выглядит следующим образом:
В верхней части утилиты задается путь к папке, в которой будут храниться тесты (xml-файлы и сценарии), а также путь к новой сборке Renga. В правой части тестировщик описывает шаги, которые необходимо произвести при записи теста. Ниже расположены кнопки для записи, проигрывания, переименования теста и т.д.
Тест записывается на протестированной руками версии приложения, поэтому данное поведение можно считать эталонным.
Чтобы записать новый тест:
- Описываем последовательность шагов в тесте и каждый момент времени, когда нужно зафиксировать состояние системы.
- Нажимаем кнопку Record: запускается Renga, и повторяем описанные выше шаги.
- Закрываем Renga — созданы эталонные xml-файлы и сценарий теста, по которым в дальнейшем можно будет выявить ошибку в функциональности, на которую написан тест.
После того, как тест успешно записан, его необходимо отправить на сервер:
- Размещаем тест в системе контроля версиями Mercurial.
- Ждем проигрывания тестов на сервере с помощью TeamCity.
Как фреймворк ловит ошибки:
- Разработчик заливает новый код в рабочую ветку.
- Собирается новая версия Renga.exe.
- На этой версии продукта проигрываются тесты и сравниваются эталонные (записанные на протестированной ранее версии) и результирующие снимки (записанные на актуальной версии).
Если снимки одинаковы — тест Passed, если хотя бы один снимок отличается — тест Failed и указаны данные xml-файлы. Если тест Failed, нужно разбираться с указанными файлами и искать причину расхождений. Ниже приведен пример сравнения эталонного и результирующего xml-файла — Gui shots:
На нем мы видим, что в результирующем файле на панели параметров “e_SpecificationParametersPanel” появилась кнопка “e_SpecificationSortDropDownButton”, которой в эталонном файле нет. По этой причине тест не пройден. Данное поведение ожидаемо, так как эта кнопка была добавлена для нового функционала. Теперь нужно считать результирующий снимок верным и сделать его эталонным. Соответственно, следующее проигрывание теста будет успешным.
А вот как выглядит проигрывание теста в нашей утилите:
Организация тестов на сервере
Тесты проигрываются на сервере после каждого залития кода в ветку.
Если хотя бы один тест не прошел, билд не выкладывается и недоступен для тестирования. Данное правило позволяет нам не тратить время на тестирование вероятно сломанного функционала, ведь пока тесты не прошли успешно, разработчик не может быть уверен, что ничего не сломано из старой функциональности.
На данный момент у нас 8 тысяч тестов, на их проигрывание уходит около 2-3 часов. То есть время доставки новой функциональности от разработчика к тестировщику составляет от 2-3 часов до одного рабочего дня, если что-то пошло не так. Такое количество тестов позволяет нам покрыть текущую функциональность, но в некоторых случаях нужно запастись терпением, чтобы дождаться рабочей сборки. Сейчас мы думаем, как ускорить получение результатов от проигрывания тестов.
Какие проблемы остались нерешенными
Утилита для тестирования решила проблему интеграции модулей, но с ее помощью нельзя протестировать GUI приложения. А это значит, что пользовательский интерфейс, работу фокуса, эмуляцию клавиш с клавиатуры, скролл, работу с несколькими окнами нам приходится тестировать только руками.
Очень часто возникают ошибки, связанные с данной функциональностью. Пытаясь решить данную проблему, мы начали искать готовый продукт для автоматизации GUI. Протестировали программу Ranorex, но, к сожалению, не все сценарии получилось протестировать с ее помощью, а к некоторым элементам управления не получилось добраться ввиду текущей реализации Renga. Поэтому мы продолжаем поиск готовых решений для тестирования пользовательского интерфейса desktop приложений и умеющих работать с Qt.
Также руками нам приходится тестировать инсталлятор. За последние месяцы мы продвинулись в этой области, начав использовать скрипты на python при помощи pywinauto. Пока что данное решение находится в зачаточном состоянии, но теперь мы видим направление, в котором нужно работать.
Подведем итоги
В нашем проекте примерно ⅔ времени тестировщик занимается ручным тестированием, пытаясь найти как можно больше ошибок и уязвимых мест, а также проверить, все ли требования соблюдены. И лишь после этого переходит к написанию автотестов, которые гарантируют, что данный функционал не сломается. С появлением автоматизированного тестирования мы обезопасили себя от повторяющихся из итерации в итерацию регрессионных ошибок. Разработчики не боятся заливать свой код в рабочую ветку, так как знают, что тесты уже через несколько часов покажут им проблемные места. А тестировщики могут целиком и полностью посвятить себя тестированию нового функционала.
Данный подход позволяет нам не морозить код на долгое время перед релизом. Фактически нам хватает одной недели на тестирование релиза и исправление критических ошибок. И это при малом количестве инженеров по тестированию и частыми релизами: мы выпускаем три-четыре релиза в год (в среднем, подобные САПР выпускают один релиз в год).
И, конечно, мы не забываем о наших проблемах. Мы будем пытаться их решить, чтобы пользователи Renga могли еще быстрее получить новую функциональность. Будем рады услышать советы, если в вашей компании были подобные проблемы и вы нашли пути их решения.
Елена Макарова, инженер по тестированию, Renga Software.
Автор: Rengabim
