Ранее мы писали о том, как это работает. тестирование КОМПАС-3D и о автоматизация тестирования интерфейса КОМПАС-3D , сегодня поговорим о тестировании BIM-системы Renga. Многие компании в процессе разработки программного обеспечения сталкиваются с проблемой ошибок регрессии.
И мы, к сожалению, не стали исключением.
В этой статье я хотел бы рассказать вам, как эта проблема проявилась в нашей стране и какие решения мы нашли.
Но сначала стоит объяснить, какую систему мы разрабатываем и как происходит процесс тестирования в нашей компании.
Что такое Ренга
Renga Architecture - архитектурно-строительная деятельность БИМ -разработана система Ренга Программное обеспечение (совместное предприятие компаний АСКОН и 1С), для создания внешнего вида здания, информационной модели, быстрой компоновки чертежей.Его пользователями являются архитекторы, дизайнеры и конструкторы.
Узнайте больше о семействе продуктов Renga (маркетинговое внимание!) Ренга Архитектура – система архитектурно-строительного проектирования.
Программа создана для оказания максимальной помощи проектировщику в решении его задач: создание архитектурного облика здания, информационная модель и быстрая компоновка чертежей в соответствии со стандартами СПДС и многое другое.
Структура Ренга — система проектирования конструктивной части зданий/сооружений.
Программа для инженеров-строителей и проектировщиков для создания информационной модели здания или сооружения и получения чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Ренга предназначен для проектирования с использованием технологии BIM. Высокая производительность систем позволяет работать с крупными проектами без видимого снижения качества работы с 3D-моделью: Объектный дизайн Создание 3D модели здания/сооружения в Renga с использованием инструментов проектирования объектов (стена, колонна, окно и т.д.) Командная работа Обмен хранилищем данных и управление ими осуществляется с помощью BIM-Server Pilot. Взаимодействие со сметными системами Интеграция Renga через API с системами 1С-смета и АВС-смета для взаимодействия проектно-сметного отдела.
Обмен данными Renga позволяет обмениваться данными с другими системами в различных форматах (.
ifc, .
dwg, .
dxf, .
obj, .
dae, .
stl, .
3ds, .
lwo и .
csv).
Автоматизация получения спецификаций и ведомостей В Renga имеется функция получения отчетов для формирования спецификаций, ведомостей и пояснений.
Автоматизация получения чертежей На основе данных 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
Ренга содержит множество инструментов, необходимых для создания архитектурной модели здания, проектирования конструктивных деталей и получения чертежей и спецификаций.
Разумеется, мы тестируем весь функционал системы.
При тестировании необходимо учитывать, что пользователь может работать с моделью как в 3D, так и в 2D, а все объекты проекта взаимосвязаны.
Сначала тестировщик вручную проверяет работоспособность и проверяет соответствие требованиям.
На этом этапе есть ошибки, которые разработчики исправят в дальнейшем.
После ручного тестирования и исправления ошибок переходим к написанию интеграционных тестов, покрывая функционал автотестами.
Далее процесс тестирования и то, как мы к нему пришли, будут описаны более подробно.
Ручное тестирование
Мы тратим много времени на тестирование вручную.Чтобы проверить работу нового объекта, например, стены, необходимо проверить:
- Постройка стены в 3D и 2D.
- Редактирование стены по характерным точкам, изменение ее свойств и параметров.
- Поведение стены при ее пересечении с другими объектами (например, плиты, колонны и балки подрезают стену).
- Делаем рисунок со стенами.
- Корректный вывод расчетных характеристик стены (длина, площадь, объем и т.д.).
- Применение и отображение стеновых материалов.
- Работа стен при вставке оконных и дверных проемов.
- Армирование стен: параметрическое армирование, расстановка сеток и каркасов в стенах.
- Локализация параметров стенок.
А теперь представьте, сколько здесь этих предметов и связей! При ручном тестировании обнаруживаются ошибки, которые трудно воспроизвести, либо они появляются при определенном состоянии системы.
Думаю, ошибки в пользовательском интерфейсе никого не удивят, но перечисленные ниже ошибки довольно интересны:
- «Некорректное отображение перил на криволинейных лестницах малого радиуса».
Вот как выглядит ошибка в приложении:
Перила «стреляют» вверх, а не располагаются на лестнице с небольшим радиусом.
- «Кнопки на панели инструментов поменялись местами».
Мы потратили около месяца на то, чтобы разобраться, в каких случаях кнопки менялись местами, так как в разных случаях происходило по-разному.
В результате были выявлены весьма необычные этапы воспроизведения: нужно вызвать контекстное меню на 3D виде, затем нажать на несколько кнопок на панели инструментов левой кнопкой мыши, выйти и вернуться на текущую вкладку с панелью инструментов и .
.
кнопки меняются местами! Ошибка начала стабильно воспроизводиться после описанных действий и была быстро устранена.
Потребовалось больше времени, чтобы научиться воспроизводить его.
Автоматизированное тестирование
Разработка нашей BIM-системы началась 6 лет назад. В самом начале разработки приложение тестировалось вручную и с помощью модульных тестов.Весь функционал был протестирован юнит-тестами, но, несмотря на это, мы начали замечать, что ломаем то, что уже было сделано ранее.
Проблема была в том, что модули работали отдельно, но их интеграция приводила к ошибкам.
Проблема разрасталась, и к юнит-тестам было решено добавить интеграционное тестирование, чтобы проверить совместную работу всех модулей системы.
Поиск готовых решений Для создания интерфейса мы используем QT -библиотека, поэтому при поиске готовых продуктов для написания интеграционных тестов мы выбрали те, которые смогут работать с этой библиотекой.
Мы рассматривали программы как возможные решения Тест завершен И Хлюпать Однако на тот момент нас не устраивали версии этих продуктов: Renga использует элементы управления, которые эти продукты не могли обнаружить и с которыми не могли работать.
А без них использование этих продуктов автоматизации было нецелесообразно.
Собственный фреймворк Мы решили написать собственный фреймворк, который будет повторять действия пользователя, работать с нужными нам элементами управления и охватывать большинство необходимых проверок.
Разработка этого фреймворка началась еще в 2012 году, и изначально приложение выглядело так: 
В процессе создания нового функционала в Renga утилита также совершенствуется.
То есть по сути мы разрабатываем два приложения одновременно: Renga и фреймворк для тестирования.
Как работает фреймворк Принцип состоит в том, чтобы записать, а затем воспроизвести сценарий, сравнивая эталонное и полученное изображения системы.
Снимки системы описываются XML-файлами, которые создаются во время записи и воспроизведения теста.
Такие XML-файлы в тесте могут быть эталонными и результирующими.
При записи теста генерируется набор эталонных xml-файлов фиксированного состояния системы, а при воспроизведении создается результирующий набор файлов.
Существуют следующие типы XML-файлов, которые отвечают за различную функциональность приложения:
- Снимки графического интерфейса — регистрация приложения с графическим интерфейсом пользователя
- Модельные снимки – данные модели
- Листы снимков – данные и чертежи чертежей
- Auxshots - положение характерных точек объекта и дополнительная геометрия
- Скриншоты – картинка в формате png, которая не сравнивается автоматически, а используется только для визуального сравнения.
- Снимки ящика - рисование объектов
- Снимки ReportCSV — экспорт данных в формат CSV
- Dxfshots - экспорт\импорт данных в формат Dxf
- Xps снимки - печать в xps
- API-шоты – тестирование API
- Снимки таблицы — рендеринг и данные таблицы
- Спецификационные снимки – технические данные
- Снимки вида спецификации - характеристики чертежей
Например, только при подготовке к последнему выпуску для тестирования.
Характеристики В утилиту добавлены снимки спецификаций и снимки просмотра спецификаций.
А также, для удобства поиска конкретных тестов, недавно была реализована система фильтрации с использованием Python-скриптов.
Теперь с помощью фреймворка можно проверять: рисование объектов, печать чертежей, экспорт и импорт объектов/чертежей в различных форматах, создание и редактирование объектов, изменение параметров и пользовательских свойств объекта, данных и рисование таблиц/спецификаций и т.д.
На данный момент структура выглядит так: 
Вверху утилиты вы указываете путь к папке, в которой будут храниться тесты (xml файлы и скрипты), а также путь к новой сборке Renga. С правой стороны тестер описывает шаги, которые необходимо выполнить при записи теста.
Ниже расположены кнопки записи, воспроизведения, переименования теста и т.д. Тест записывается на проверенной вручную версии приложения, поэтому такое поведение можно считать эталонным.
Чтобы записать новый тест:
- Опишем последовательность шагов в тесте и каждый момент времени, когда нам нужно записать состояние системы.
- Нажмите кнопку «Запись»: запустится Renga, и повторите действия, описанные выше.
- Закрываем Renga — созданы эталонные xml файлы и тестовый скрипт, который в дальнейшем будет использоваться для выявления ошибки в функционале, для которого написан тест.
- Размещаем тест в системе контроля версий Меркуриальный .
- Ждём тестов для игры на сервере с помощью TeamCity .
- Разработчик загружает новый код в рабочую ветку.
- Создается новая версия Renga.exe.
- В этой версии продукта воспроизводятся тесты и сравниваются эталонные изображения (записанные на ранее протестированной версии) и результирующие изображения (записанные на текущей версии).
Если тест не пройден, нужно разобраться с указанными файлами и искать причину расхождений.
Ниже приведен пример сравнения эталонного и полученного XML-файла — снимки Gui: 
Здесь мы видим, что в полученном файле на панели параметров «e_SpecificationParametersPanel» появилась кнопка «e_SpecificationSortDropDownButton», которой нет в эталонном файле.
По этой причине тест провалился.
Такое поведение ожидаемо, поскольку эта кнопка была добавлена для новых функций.
Теперь вам нужно считать полученное изображение правильным и сделать его эталоном.
Соответственно, следующее тестовое воспроизведение будет успешным.
А вот как выглядит воспроизведение теста в нашей утилите: 
Организация тестов на сервере
Тесты проигрываются на сервере после загрузки каждого кода в ветку.
Если хотя бы один тест не пройден, сборка не публикуется и недоступна для тестирования.
Это правило позволяет нам не тратить время на тестирование возможно сломанного функционала, поскольку пока тесты не пройдут успешно, разработчик не может быть уверен, что из старого функционала ничего не сломано.
На данный момент у нас 8 тысяч тестов, на их прохождение уходит около 2-3 часов.
То есть срок доставки нового функционала от разработчика к тестировщику составляет от 2-3 часов до одного рабочего дня, если что-то пойдет не так.
Такое количество тестов позволяет нам охватить текущий функционал, но в некоторых случаях нужно набраться терпения и дождаться рабочей сборки.
Сейчас думаем, как ускорить получение результатов от игровых тестов.
Какие проблемы остаются нерешенными? Утилита тестирования решила проблему интеграции модулей, но ее нельзя использовать для тестирования графического интерфейса приложения.
Это означает, что нам придется тестировать пользовательский интерфейс, работу фокуса, эмуляцию клавиш клавиатуры, прокрутку и работу с несколькими окнами только вручную.
Очень часто возникают ошибки, связанные с этим функционалом.
Пытаясь решить эту проблему, мы начали искать готовый продукт для автоматизации GUI. Протестировал программу Ранорекс , но, к сожалению, не все сценарии удалось протестировать с его помощью, а к некоторым элементам управления не удалось получить доступ из-за текущей реализации Renga. Поэтому мы продолжаем поиск готовых решений для тестирования пользовательского интерфейса десктопных приложений, умеющих работать с Qt. Нам также придется протестировать установщик вручную.
За последние месяцы мы добились прогресса в этой области, начав использовать скрипты Python с помощью pywinauto. Пока это решение находится в зачаточном состоянии, но уже сейчас мы видим направление, в котором нам нужно работать.
Давайте подведем итоги
В нашем проекте около ⅔ времени тестировщик занимается ручным тестированием, стараясь найти как можно больше ошибок и уязвимостей, а также проверить, выполняются ли все требования.И только после этого он переходит к написанию автотестов, гарантирующих, что этот функционал не сломается.
С появлением автоматизированного тестирования мы защитили себя от ошибок регрессии, повторяющихся от итерации к итерации.
Разработчики не боятся загружать свой код в производственную ветку, поскольку знают, что тесты покажут им проблемные места в течение нескольких часов.
А тестировщики могут полностью посвятить себя тестированию нового функционала.
Такой подход позволяет нам не замораживать код на долгое время перед релизом.
На самом деле нам достаточно одной недели, чтобы протестировать релиз и исправить критические ошибки.
И это при небольшом количестве инженеров по тестированию и частых релизах: мы выпускаем три-четыре релиза в год (в среднем аналогичные САПР выпускают один релиз в год).
И, конечно, мы не забываем о своих проблемах.
Мы постараемся их решить, чтобы пользователи Ренга могли бы получить новую функциональность еще быстрее.
Будем рады услышать советы, если в вашей компании возникали подобные проблемы и вы нашли пути их решения.
Елена Макарова, инженер по тестированию Renga Software.
Теги: #тестирование #тестирование #автоматическое тестирование #качество для #bim-систем #CAD #CAD #тестирование ИТ-систем #Qt #разработка для Windows
-
Надежные Источники Загрузки Игр Для Wii
19 Oct, 24 -
Переход В Облако: 5 Разных Историй
19 Oct, 24 -
Когда Быть Хорошим – Плохо
19 Oct, 24
