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

Сегодня поговорим о Магнитофоне. Так называется система автотестирования нашей собственной разработки. С её помощью можно записывать и анализировать тесты по заданным сценариям. Такая работа помогает:

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

Слово берёт оператор Магнитофона, инженер по тестированию КОМПАС-3D Максим Горшков.

Как происходит тестирование

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

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

Тестовый сценарий, описанный в формате xml

Проверка результатов тестирования

Для того, чтобы определить, правильно ли выполнен тест, используются снэпшоты – снимки состояния программы на текущий момент. Магнитофон делает снэпшот в указанное время и сравнивает его с эталонным, который был сделан при записи теста, либо обновлён при изменении функционала.

Как выглядит сравнение результатов? У нас есть снимок рабочей области, где красным цветом выделены отличия модели от ожидаемого результата. Различия в интерфейсе подсвечиваются фиолетовой рамкой, и тестировщик может анализировать их, чтобы заменять в будущем эталоны для тестирования.

Эталонный снимок рабочей области (сверху свободное место)

Определение вылетов Undo/Redo

Много информации об ошибках приходит к нам от конечных пользователей в системе по сбору данных Crashboard. Анализ пользовательских данных выявил большое количество вылетов при нажатии комбинации клавиш ctrl+z/ctrl+y, подразумевающих «Отменить действие» и «Повторить действие» или Undo/Redo. Иногда информация о вылетах сопровождается описаниями, приблизительными или неполными. Тестировщики пытаются повторить эти действия вручную, но не каждый из сценариев воспроизводит вылет.

У нас появилась идея использовать для массового исследования этих функций имеющуюся базу написанных тестов Магнитофона. На данный момент это 11000 тестов. В ходе исследования возникла проблема: среди этих тестов использование комбинации «отменить и повторить действие» было записано только в 150 случаях и только по определённым сценариям. Нужно было внедрить Undo/Redo в оставшиеся тесты с максимальной эффективностью.

В результате анализа проблемы я пришёл к выводу, что самыми подходящими местами для внедрения Undo/Redo в тесты являются «Создание операции» (зелёная галка) и «Выход из операции» (красный крест), а также место перед каждым созданием снэпшота для сравнения. Для начала я исключил из общей базы тестов те сценарии, в которых отмена и повторение и действий были недоступны. В результате осталось 6000 тестов. Каждый из них нужно было открыть, в нужных местах добавить строки с Undo/Redo и сохранить изменения.

Внедрённая комбинация Undo/Redo в теле теста

Чтобы одновременно внести изменения в такое большое количество тестов, я воспользовался специализированной утилитой для быстрого поиска и замены строк в текстовых файлах. В процессе развития Магнитофона синтаксис записи тестов несколько раз менялся: пробелы добавлялись то в одном, то в другом месте. Это осложняло поиск ключевых строк. Но в итоге все 6000 тестов были успешно отредактированы.

Проведение экспериментальных прогонов

Первые эксперименты я проводил локально на собственной рабочей машине. Расчётное время каждого прогона составляло от 50 до 60 часов. Естественно, ни один тестовый прогон не дошёл до финиша. Поэтому следующие эксперименты я ставил на специально выделенной виртуальной машине.

На ней были получены первые результаты — сценарии вылетов, которые не были найдены при ручном тестировании. После я получил разрешение на использование полного объёма ресурсов, благодаря чему проверка ускорилась с 60 часов до 2,5 часов. Это позволило найти и другие ошибки. Вот результаты одного из прогонов:

Меня интересовали именно провальные тесты, потому что на самом деле «Провал» в случае моего исследования — это успех: он означает, что, возможно, это именно тот сценарий вылета, который мы ищем.

Результаты проделанной работы

В ходе работы возникали сложности. Выяснилось, что для надёжности работы лучше пользоваться горячими клавишами, а не непосредственным нажатием кнопок в интерфейсе. Потому что если кнопка по какой-то причине недоступна, тест завершится с ошибкой: «не удалось выполнить нажатие кнопки «Кнопка_name». Также при внедрении дополнительных команд в тесты время их выполнения увеличилось и превысило установленный порог, что приводит к ошибке - Таймауту.

На сегодняшний день благодаря выполнению тестового прогона в полном объёме я смог найти 8 сценариев вылетов, несколько ошибок и утечки памяти. Написал первичную инструкцию выполнения прогона, а также участвую (как заказчик) в разработке скрипта для полной автоматизации процесса подготовки прогона. Но самый важный результат — некоторые найденные ошибки уже исправлены нашими программистами, а исправления доступны конечным пользователям.

Анализ, выводы и обработка результатов

Мы решили повторять такие прогоны с периодичностью 1,5-2 месяца для своевременного выявления новых случаев вылетов или ошибок программы по Undo/Redo. Сейчас разрабатываем функционал, который позволит создавать репозиторий с тестами автоматически и сразу модифицировать их так, как нам нужно. После получения и обработки результатов такого прогона, ненужный репозиторий можно будет удалить.

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

Разработана целая методика применения «фаззинга» в системе Магнитофон. Она открывает возможность создания аналогичных масштабных прогонов тестов для проверки других сценариев. Например, когда получаем результаты прогонов с большим количеством ошибок, необходимо проанализировать полученные данные и определить причину поломки тестов, что вызывает определённые сложности. Для начала нужно отфильтровать ошибочные тесты по типу ошибок. Для этого существует специальный функционал, но для его использования необходимо обладать дополнительными знаниями.

Например, чтобы создать фильтр по типу ошибки, необходимо описать условия фильтрации в виде кода на языке Python. В нём мы должны будем скомбинировать различные критерии поиска ошибок для фильтрации.

Код на Python, описывающий правило фильтрации

Перспективы работы с Магнитофоном

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

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

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

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

Оптимизация тестирования: как поймать вылеты автотестами. Что нам подсказал Магнитофон