Как устроено тестирование у разработчиков КОМПАС-3D

    Недавно вышла новая версия САПР КОМПАС-3D v17, но вплоть до самого финального релиза в систему еще вносились изменения, тестирование продолжалось. О том, какие испытания проходил новый КОМПАС-3D, прежде чем попасть к пользователям, рассказывает команда КОМПАС-3D из Центра разработки АСКОН в Коломне.

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


    «Долина Дали» автор Дмитрий Верба

    При проверке такой сложной системы, как КОМПАС-3D, без ручного тестирования обойтись нельзя. Все тестировщики, выполняющие ручное тестирование, имеют опыт конструкторской работы на производстве и не понаслышке знают, как и зачем пользователи применяют ту или иную функциональность КОМПАС-3D.

    Ручное тестирование



    Евгений Филимонов, инженер по тестированию 3D:

    Мы смотрим на КОМПАС-3D со стороны пользователя, то есть фактически проектируем сами. При тестировании какой-либо операции, к примеру, Выдавливание, мы проверяем все возможные способы её выполнения; рассматриваем варианты использования в сочетании с другими объектами: отдельно Выдавливание может работать правильно, а в массивах или исполнениях — уже нет. В общем, придумываем самые разные сценарии — у тестировщиков хорошо развита фантазия. При этом стараемся, чтобы сценарии были близки к пользовательским. Хотя иногда бывает полезно рассмотреть и экзотические случаи.


    Некорректное построение скругления (Картинка кликабельна).

    В v17 произошли столь кардинальные изменения (относительно предыдущих версий), что работ и по кодированию, и по тестированию было намного больше, чем обычно. Особого внимания с нашей стороны потребовала, например, операция По сечениям, в которую были внесены значительные доработки, в том числе связанные с новыми математическими алгоритмами. Тестирование этой операции идет на протяжении всей разработки версии.

    Особенности новой операции По сечениям
    в КОМПАС-3D v17 в операции По сечениям появилась возможность управлять соединением сечений с помощью цепочек и направляющих кривых.


    Направляющие кривые в операции По сечениям(Картинка кликабельна)

    Как это устроено: тест-планы.


    Когда тестировщик приступает к работе, он составляет тест-план. Рассмотрим упрощенный пример — отрезок. Его можно строить по двум точкам, по длине и углу; отрезок может быть построен между объектами, в разных слоях, определенным стилем кривой. Все эти нюансы при построении отрезка, его редактировании или удалении тестировщик описывает в тест-плане. План содержит несколько частей: непосредственно функциональность (к примеру, построение по длине и углу), защита (нет лицензии — построение не выполняется), вывод на печать (при печати отрезок должен отображаться в соответствии с заданным стилем кривой) и так далее. Тест-план оформляется в виде «дерева мысли», и именно на него тестировщик ориентируется при проверке работы системы. Однако тест-план покрывает только основные сценарии, в нём невозможно предусмотреть 100% вариантов использования, т.к. их, по сути, может быть бесконечное множество.

    Тестирование пользовательского интерфейса



    Екатерина Родина, инженер по тестированию интерфейса:

    Интерфейс — это «лицо» программы. В отличие от функциональности 2D или 3D, где тестируются конкретные операции, интерфейс приходится проверять по всей системе, т.к. КОМПАС-3D должен сохранять свое лицо при выполнении любой операции (команды), в любом из компонентов. Хороший интерфейс обеспечивает комфортное восприятие и работу в системе. Он должен выглядеть аккуратно, чтобы все тексты четко отображались на экране, иконки хорошо масштабировались. Удобство проверяется по расположению кнопок, количеству кликов, которые необходимо пройти до нужной команды.

    Каждая операция формируется с помощью определенного набора элементов интерфейса — контролов. Таких элементов насчитывается около 50-ти: поле для ввода текста, поле с выпадающим списком, поле для слежения за курсором и т. д. Каждый контрол тестируется отдельно. Мы проверяем, как выглядит контрол, следит ли он за курсором, выдает ли сообщения о вводе неверного значения, работает ли с текстовым метками и выражениями.


    Ошибка: пропал текст (Картинка кликабельна).

    Помимо отдельных контролов проверяются все панели и диалоги: внешний вид, размер, поведение при перемещении, удобство использования.


    Цвет иконки ошибочно стал черным (Картинка кликабельна).

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

    С помощью «Магнитофона» осуществляется контроль не только работы, но и положения элементов интерфейса, отображаемых в текущий момент времени. В КОМПАСе очень много команд. Чтобы не искать глазами, какой элемент изменил свое положение, мы автоматизировали этот процесс. Тесты перебирают по очереди все команды, проверяя, чтобы элементы находились на своих местах.


    Видео работы «магнитофона»

    Как это устроено: «Магнитофон».


    Программа записывает и воспроизводит действия тестировщика, сигнализируя о появлении ошибок. «Магнитофон» видит в КОМПАС всё: элементы интерфейса и объекты документов, понимает, в каком они состоянии, может ими управлять. Изначально предназначенный для тестирования пользовательского интерфейса, он удачно применяется и для проверки функциональности. Его использует большинство сотрудников разработки: тестировщики, программисты, аналитики. Для v17 — это вообще основной инструмент автоматизации тестирования. В подразделении разработки «Магнитфон» по сложности и по выделяемым на него ресурсам является вторым продуктом после КОМПАСа — без него отлаживать v17 было бы очень сложно и долго.

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


    Алексей Чирва, руководитель группы автоматизированного тестирования:

    Одно из направлений автоматизированного тестирования КОМПАС-3D — обеспечение корректности пользовательских документов, созданных в предыдущих версиях. Мы должны убедиться, что все пользовательские наработки будут вести себя ожидаемо в новой версии: к примеру, сборка не разлетится, не поменяется ее цвет, комплектация, спецификация. База документов, используемых в тестах, насчитывает более 700 000 работ. Из них формируются наборы по определенным критериям.

    Основные сценарии проверки корректности пользовательских документов направлены на выявление изменений и ошибок в геометрии.


    Ошибки в геометрии моделей (Картинка кликабельна)

    Отдельного внимания требует тестирование импорта и экспорта всех поддерживаемых форматов документов. Мы проверяем корректность результатов конвертации (геометрию, формат записи, размер файлов), выполняем замеры производительности.

    При тестировании производительности КОМПАС-3D отслеживается время выполнения операций, время отклика интерфейса, расходование системных ресурсов, скорость отображения моделей и чертежей и т.д.

    Тестирование математики



    Сергей Бирюков, математик-программист C3D Labs:

    Вышла не только новая версия КОМПАС-3D, но и новая версия геометрического ядра C3D. Обычно достижения ядра практически сразу попадают в КОМПАС-3D, мостик между ними очень короткий. Функциональность, которую мы сейчас добавляем, может быть сразу протестирована в КОМПАСе. Кроме этого, определенные методы ядра невозможно полноценно проверить без использования КОМПАСа, например, тестирование сопряжений геометрических элементов. Тестирование ядра внутри подразделения C3D Labs происходит исключительно в автоматическом режиме. Первый этап тестирования — это юнит-тесты, запускаемые в течение дня при каждой новой сборке ядра на каждой ревизии. Кроме этого, три раза в день проходят тесты из небольшого набора моделей, проверяющие построение ассоциативных видов, перестроение моделей и конвертацию из различных форматов данных. Обнаруженные ошибки чаще всего исправляются днем, чтобы к вечеру сдать максимально чистую, без поломок, ревизию (изменение кода) ядра. Ночью на внутреннем сервере запускается большое регрессионное тестирование на базе из 400 000 моделей в формате ядра c3d. И уже следующим утром всем программистам C3D Labs рассылается сообщение с итогами тестов.


    Отчёт о работе АСТ (автоматической системы тестирования) ядра C3D

    Удобство нашей системы тестирования состоит в том, что в случае неудачных результатов автоматически определяются все изменившиеся модели, и для каждой из них обнаруживается ревизия, на которой произошли изменения. Поэтому в сгенерированном утреннем письме уже содержится полный список этих моделей с указанием номера и автора ревизии, вызвавшей изменения. Если большое тестирование прошло без ошибок, то ревизия, на которой оно было выполнено, считается качественной рабочей версией ядра. Мы собираем КОМПАС-3D с новым ядром и передаем его разработчикам КОМПАСа. Они проверяют эту сборку на базовом тесте, и если все хорошо, данная версия математики сдвигается в КОМПАС-3D.

    Тестирование приложений


    Лариса Иванова, инженер по тестированию приложений:

    Основной задачей в версии v17 было «подружить» приложения с новым интерфейсом КОМПАС-3D. Чтобы это знакомство прошло гладко, мы подключились к процессу тестирования задолго до того, как к адаптации приложений приступили их разработчики. Для начала надо было убедиться, что приложения подключаются. Затем началось тестирование каждого приложения в отдельности: подключение, запуск каждой команды, отображение иконок, запуск процессов, появление диалогов, проверка работы по типовым сценариям —


    Приложение Оборудование: Сварные соединения. Все параметры выбраны, а кнопки «Создать объект» нет (Картинка кликабельна).

    функциональность приложений не должна была стать хуже, чем в предыдущих версиях.


    Приложение Размерные цепи. Не отображаются иконки команд (Картинка кликабельна).

    Все ошибки мы систематизировали — отделили ошибки, «наведенные» доработками в интерфейсе, от ошибок самих приложений — и отправили на доработку. И только когда приложения стали работоспособными, их разработчики подключились к работе над новым интерфейсом.

    После того, как разработчики завершили свою часть, началось функциональное тестирование приложений — по сути, разработка реальных проектов, включающая проектирование и получение конструкторской документации. Мы вручную запускали все команды приложений, проверяли работу каждой кнопки, сравнивали с работой в предыдущих версиях. При обнаружении проблем, а также при появлении новых возможностей и выявлении особенностей, оповещали разработчиков приложений через Систему управления релизами, разработанную нами для предыдущих версий КОМПАСа, но в полной мере оцененную именно в v17.


    Приложение Оборудование: Металлоконструкции. Команда Специальная разделка. Результат выполнения операции не соответствует заданным параметрам (Картинка кликабельна).

    Да, приемы работы и интерфейс в КОМПАС-3D v17 изменились кардинально. Но благодаря команде тестирования АСКОН, не раз и по-разному испытавшей версию на себе, пользователи могут быть спокойны — КОМПАС-3D v17 решит любые их задачи.
    АСКОН 89,84
    Крупнейший российский разработчик инженерного ПО
    Поделиться публикацией
    Комментарии 33
    • +1
      Сколько у вас тестировщиков в команде?)
      • 0
        Вроде 12. Смотря какую команду считать. Часть тестировщиков в группах, остальные непосредственно в отделе тестирования.
        • 0
          Пересчитал всех — оказалось 16 тестировщиков. Это в КОМПАСе и приложениях.
        • 0
          Неужели у вас для каждого вида тестирования — отдельный инженер по тестированию?
          • +1
            Для каждого вида тестирования у нас несколько инженеров по тестированию. Интервью не у всех же брали. Несколько человек в отделе тестирования занимаются автоматизацией, несколько человек ручным тестированием. Плюс ещё один-два тестировщика в группах разработки — они сразу проверяют сделанное программистами до слива в общий код.
          • 0
            Спасибо за статью, очень интересно знать как коллеги по ремеслу организуют работу в их условиях. Может расскажете еще про подход к разработке (какая модель используется, как работаете с требованиями) и про длительность цикла между версиями?
            • +1
              про длительность цикла между версиями?

              17я разрабатывалась довольно долго. Почти 4 года. При этом часть разработки делала 16ю версию, которая вышла 2 года назад. До этого версии выходили почти каждый год.
              какая модель используется

              Agile с элементами водопада) Мы сейчас в процессе перехода на гибкие методологии.
              как работаете с требованиями

              Тут тоже в процессе перехода от классических ТЗ с формальными требованиями к Use Case, User story. Требования проходят несколько стадий — создание, согласование, тестирование. Стремимся к внедрению практик гибкой разработки (scrum).
              • 0
                Спасибо! Я сразу почувствовал серьезный и просчитанный процесс, больше свойственный для традиционных моделей. Если не секрет, насколько вы довольны текущим процессом? Я в последнее время работаю только с гибкими методологиями, и мне очень любопытно узнать, как, в современных условиях, получается делать классный софт по традиционным моделям.

                Может быть получится больше понять границы применимости… Все таки, конструкторская работа — еще и стандартизируемая, т.е. чертежи должны оформляться по ГОСТ, и это тоже не способствует использованию Agile. Как вы думаете?
                • 0
                  насколько вы довольны текущим процессом?

                  Всегда можно найти недовольных и довольных) Совещаться в группах удобнее, когда все рядом. С другой стороны тестировщики/аналитики находясь среди программистов хуже обмениваются опытом между собой — начинают думать как программисты, что не всегда хорошо… Поэтому отделы не были ликвидированы полностью — оставлен отдел тестирования — как некий аналог ОТК на заводе. Часть аналитиков также сведены в отдел аналитики. Оставленные отделы позволяют также обучать новых сотрудников.
                  очень любопытно узнать, как, в современных условиях, получается делать классный софт по традиционным моделям.

                  Ну мы довольно далеко ушли от чисто традиционной модели. 17я разрабатывалась уже по гибкой методологии.
                  Может быть получится больше понять границы применимости… Все таки, конструкторская работа — еще и стандартизируемая, т.е. чертежи должны оформляться по ГОСТ, и это тоже не способствует использованию Agile. Как вы думаете?

                  Чтобы оформить чертёж по ГОСТ, можно применять разные инструменты. В рамках Agile эти инструменты можно совершенствовать. Мы же не сам ГОСТ разрабатываем)
            • 0
              Некоторое время пользовался Компасом, из того, что тогда удивило: на вашем сайте не нашел предложения скачать заплатки, обновления и т.д. Возможно оно где то в глубине и есть, но обычно это как то более наглядно и доступно.

              В процессе работы получались документы с поехавшей геометрией, потерянными базовыми плоскостями, экскизами, которые после редактирования стали выглядеть не так, как раньше и т.д. Что с такими документами делать — не понятно. Показывал их вашему сотруднику, который ведет блог на 3дтудей, — да, он помог несколько раз исправить конкретный документ, но никаких патчей, которые устраняли бы проблему, так и не вышло. В новой версии тоже ничего исправлять не будете до следующего релиза?
              • 0
                на вашем сайте не нашел предложения скачать заплатки, обновления и т.д.

                Для профессиональной версии они все находятся в личном кабинете.
                По домашней версии патчи и сервис-паки не выпускались — не было возможности у разработки из-за большой загрузки по 17й версии.
                В новой версии тоже ничего исправлять не будете до следующего релиза?

                Домашняя версия выйдет сразу с сервис-паком. В дальнейшем, если будут критичные проблемы, будем выпускать патчи.
              • 0

                Меня, как студента, интересует пока что 16 версия. После патча, продлевающего лицензию, производительность программы упала настолько, что поставить обычный отрезок — дело 2-3 минут (не быстрое совсем), а если на него поднажимать, то виснет наглухо. Такое поведение наблюдается еще у нескольких одногруппников и так же после патча (без него, очевидно, он совсем не запускается). Мой комп не назвать слабым, да и программа сидит на твердотельнике, так что поведение считаю крайне странным.

                • 0
                  После патча, продлевающего лицензию, производительность программы упала настолько, что поставить обычный отрезок — дело 2-3 минут

                  Это не может быть с патчем связано. Проблема была бы массовой.
                  Почистите конфиги и обновите драйвер видеокарты.
                  • 0
                    Если не помогло, обратитесь в техподдержку.
                    Вот личный кабинет:
                    https://sd.ascon.ru/otrs/customer.pl
                    Если есть проблемы с регистрацией, воспользуйтесь почтой:
                    support@ascon.ru
                  • 0
                    столкнулся с непонятным: в демо-версии Компас 17 не работает переключение по полям ввода кнопкой Tab, (например при вводе параметров отрезка, не переключается сразу табом на ввод угла). Это специально сделано, или ошибка? (да, если несколько раз нажать таб, то вроде доходит до угла — но это не то, к чему привыкаешь, работая интуитивно в предыдущих версиях). Не могли же разработчики и тестировщики упустить такую важную вещь?
                    • 0
                      Порядок табуляции надо прописывать в каждом окне и на каждой панели отдельно. Это требует довольно больших трудозатрат, а используется относительно малым количеством пользователей. Поэтому пока отложили эту функциональность. В последующих обновлениях должно появится.
                      • 0
                        это самый странный ответ, который можно себе представить.
                        • 0
                          Удивляет большая трудоёмкость или то, что нужно прописовать порядок табуляции?
                          • 0
                            хм. ок… я просто привык к переключению табом между окнами ввода (мне кажется, это какой-то стандарт естественный при работе, в том же автокаде) — и почему вдруг этот момент упущен, вы же пишете — 4 года разрабатывали? давайте так: просто запишите это куда-нибудь в памятку ответственному разработчику и пусть сделает в SP1. Будем ждать. А сложно или нет — это пользователей не должно волновать. Это проблемы разработчика. Прописывать НУЖНО однозначно, иначе теряется интуитивность работы с клавиатуры. (заметьте, я написал это в комментариях к статье про тестировщиков, которые эту фичу пропустили)
                            • 0
                              я просто привык к переключению табом между окнами ввода

                              Я вас понимаю. Людям, которые привыкли работать с клавиатурой, тяжелее всего в данной ситуации, сам такой.
                              и почему вдруг этот момент упущен, вы же пишете — 4 года разрабатывали?

                              Времени никогда не хватает. Проделанная работа просто огромна. КОМПАС по сути был полностью переписан. При этом нереализована ещё довольно заметная часть функционала, которая будет доделываться в обновлениях.
                              куда-нибудь в памятку ответственному разработчику и пусть сделает в SP1. Будем ждать

                              Как я уже написал: в последующих обновлениях это должно появится.
                    • 0
                      Спасибо за интересную статью. Есть пара вопросов.
                      1. Время отклика интерфейса определяется в каждом отдельном случае? Или для всех компонентов одинаковое время отклика? Как определяется, что один интерфейс может грузиться, скажем, 0.1 сек, а второй — 5 сек?
                      2. Можно подробнее про Магнитофон? Он пишет только координаты мышки и сообщения мыши/клавы? Или может смотреть во вьюпорт и работать напрямую с объектом во вьюпорте (скажем, если я хочу выделить объект, Магнитофон запишет нажатие ЛКМ по координатам, или он запишет событие выбора объекта по его ID/хешу?)? Аналогично, когда Магнитофон кликает по кнопкам интерфеса, кликает по координатам или по ID кнопок?
                      3. Как боретесь с крашами? При работе с графикой, юз кейсов и их комбинаций может быть миллиарды, и всех их при тестировании не предусмотреть; нет-нет, да какой-то краш будет пропущен. Как их находите, как фиксите, если шаги не очевидны?
                      • +1
                        2. Можно подробнее про Магнитофон?

                        Готовим отдельную статью.
                        1. Время отклика интерфейса определяется в каждом отдельном случае? Или для всех компонентов одинаковое время отклика? Как определяется, что один интерфейс может грузиться, скажем, 0.1 сек, а второй — 5 сек?

                        Грузится только интерфейс без модели или чертежа. Если стал грузится медленнее — программисты ищут у себя ошибку.
                        3. Как боретесь с крашами?

                        По-моему вылет проще всего найти. Если он произошел при выполнении автотеста, надо просто повторить те действия, которые были до него. Если действия производятся регулярно достаточно два-три последних повторить.
                        • 0
                          Это хорошо. если автотест словил. Вопрос в том, что делаете, если автотест не словил, а краш есть.
                          • 0
                            Если при ручном тесте — вспоминаем, что делали до этого, записываем и начинаем перебирать варианты, как упростить сценарий.
                        • 0
                          2. Можно подробнее про Магнитофон?

                          Опубликовали:
                          https://habrahabr.ru/company/ascon/blog/327266/
                        • 0
                          Позвольте поинтересоваться — не ожидается ли порта Вашего изделия под linux?
                          • 0
                            В ближайшее время нет.
                            • 0
                              Очень жаль. Пляски с вайном утомляют, а в шестнадцатом выпуске компаса библиотека стандартных изделий демонстрирует очень странное поведение — замечательно открывается, замечательно всё показывает, но не создаёт ни одного объекта, при этом в консоли ошибок нет.

                              Я понимаю, что Вы будете ссылаться на отсутствие спроса со стороны *nix-осей, и, конечно, у Вас есть какая-то объективная статистика, но, тем не менее — нам, линуксоидам, Ваше изделие нужно, и мы готовы платить деньги за корпоративные релизы.
                              • 0
                                Обращайтесь в региональные офисы, пишите об этом в техподдержку support@ascon.ru, чтобы мы могли оценить спрос.
                                • 0
                                  у меня есть встречное, возможно лучшее предложение — может вы сделаете рассылку на ваших пользователей с лицензией с вопросом, заинтересованы ли они в версии под Linux и сколько они готовы заплатить. Тогда вы сможете оценить ROI и реальный спрос платежеспособной целевой аудитории.
                                  • 0
                                    Очевидно, что у наших текущих пользователей уже есть Windows, и они не захотят менять всю инфраструктуру и переучивать персонал. Интересен тот рынок, на котором нас сейчас нет, а не тот, где мы уже есть.
                                    • 0
                                      Запустите опрос у себя на сайте.
                                      • 0
                                        Как нам поможет анонимный опрос?
                                        Нам нужны реальные заказчики, которые будут платить деньгами, а не отвечать на вопросы в интернете.

                                        Если вы потенциальный заказчик, я для вас писал:
                                        Обращайтесь в региональные офисы, пишите об этом в техподдержку support@ascon.ru

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое