Тестирование десктопа: что учитывать перед введением автотестов

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

Мы решили пойти по второму пути: добавить автодеплой и автоматизировать часть регрессионных тестов, чтобы команда не тратила время и силы на рутинные процессы, а могла заняться бизнесовыми задачами. Вот как это было.

Анастасия Исаева

Старший эксперт по тестированию

Как мы пришли к нынешнему устройству системы

Большинство сотрудников проходит три стадии принятия при такой ситуации.

• Отрицание — не может быть, что кто-то в 2023 ещё работает на системе, написанной на Delphi?
• Гнев — почему то, что мне нужно, работает, только если обладаешь тайными знаниями?
• Принятие — система работает стабильно, большинство доработок можно сделать достаточно просто — и уже понятно, как их проверять.

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

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

После этого наладили CI/CD процесс. Все внутренние доработки по системе теперь обязательно ставятся через Git. До этого разработчики на все филиалы ставили доработки руками, что отнимало много времени и увеличивало количество ошибок и расхождений в разных базах.

В дополнение к существующим сложностям у системы есть особенность: доработки идут как от вендора, так и от внутренней команды разработки. Таким образом, внутренние обновления ставятся через Git On Demand по готовности, а доработки вендора также через Git, но в рамках релизов.

Это связано с тем, что система — монолит, и вендор поставляет ряд доработок как чёрный ящик. Поэтому возникает необходимость проводить полноценное регрессионное тестирование всей системы из-за возможного влияния доработок на смежные модули.

Как мы выстроили процесс автоматизации

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

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

1. Ускорили проведение проверок.
2. Упростили автоматизацию, так как изменения от кейса к кейсу незначительные.
3. Повысили мотивацию команды, так как они стали тратить меньше времени на рутину.

Далее для облегчения процесса автоматизации подробно описали тест-кейсы с шагами, без ветвлений. Хорошо описанная тестовая модель полезна не только для автоматизации, но и в целом для качественной оценки количества работы, выполняемой командой.

Например, мы спросили, какие тесты рутинные? Нам скинули один из кейсов. Проанализировав его, мы обнаружили, что он содержит несколько ветвлений. Мы декомпозировали кейс, и вместо одного получили более ста независимых. Именно поэтому он и оказался в списке на автоматизацию.

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

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

Также, начиная автоматизировать систему, важно учитывать, что даже в случае с UI-тестами не всё обязательно делать через UI. Например, предварительные данные или ряд итоговых проверок можно сделать, используя хранимые процедуры.

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

Мы идём к такому идеалу: когда появляются новые продукты, к ним стоит сразу писать автотесты. Мы хотим перейти к модели, при которой в момент разработки нового сервиса тут же будет ставиться задача на автоматизацию. И когда сервис готов — запускаться автотест, также написанный по документации. Если он отработает — сервис выкатится. Если нет, то его доработают.

Какие инструменты мы используем

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

Вот что мы выбрали для себя.

Micro Focus Unified Functional Testing

Позволяет определить объекты на форме десктопного приложения: окно, radio-button, выпадающий список, поле для ввода. На основе этого к добавленному в библиотеку объекту можно применить то или иное действие: нажать на кнопку или закрыть окно.

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

• Zeenyx,
• Winium,
• Katalon Studio,
• Test Complet Desktop.

Можно выбрать тот, который подходит именно вам.

Pywinauto

Это open source библиотека для автоматизации десктопных GUI приложений на Microsoft Windows. Он нужен для ряда проверок, например, для операций с длительным ожиданием.

Тестирование на PyTest

Если это доработка вендора и тестирование чёрного ящика, где нужно убедиться, что у реальных пользователей не будет ошибок, мы пишем интерфейсные тесты, используя приведённые выше инструменты. А если нужно проверить интеграционный сервис — API-тест, написанный на Python.

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

Python + PyTest позволяют достаточно легко это сделать. А также дают возможность встроить в пайплайн запуск в момент изменения сервиса или связанной процедуры.

Git и TeamCity

Для поддержания версионности и развёртывания кода. Как единый стандарт в банке. Автотесты мы ведём там же, что упрощает выстраивание общего процесса.

Использование ранее написанных процедур при подготовке данных

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

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

Лучшие практики, чтобы выстраивать CI/CD на десктопе

Тестирование — важная часть CI/CD-процесса, который постоянно совершенствуется. Всегда можно найти более эффективные практики, которые помогут избежать проблем в будущем. Вот ещё несколько принципов, которые помогают улучшить этот процесс.

• Должно быть версионирование кода. Если сейчас у вас этого нет, нужно начинать делать шаги к этому.
• Версионирование кода касается в том числе автотестов.
• Подробно описывайте тест-кейсы, это помогает как с погружением новых сотрудников, так и с написанием автотестов.
• Учитывайте техокна на интеграционных стендах. Если доставлять обновления, не обращая на это внимание, можно помешать другим командам работать. Если в моменте кто-то незапланировано что-то поставит, всё зависнет или вообще сломается.
• Используйте Feature toggle. Он помогает безболезненно поставить доработки на пром, даже если они не работают с включенным toggle.
• Пишите тесты, а лучше автотесты, до того, как доработку передали в тестирование. Писать тест-кейсы, когда доработки уже готовы, — это плохая практика, можно нахватать проблем, например, не хватит сотрудников, чтобы провести тестирование.
• Чем раньше привлекается тестирование, тем лучше. Ведь уже на этапе прочтения ТЗ можно увидеть слабые места, задать вопросы, исправить их и сделать сразу правильно.