- PVSM.RU - https://www.pvsm.ru -
Не знаю, как вы, но я в воде чувствую себя уверенно. Однако недавно меня решили научить плавать снова, применив старый спартанский метод: кинули в воду и велели выживать.
Но довольно метафор.
Дано: PhoneGap-приложение с iframe, внутри которых загружается сторонний сайт; стаж тестировщика 1,5 года; стаж программиста 0 лет.
Задача: найти способ автоматизировать тестирование основного бизнес-кейса приложения, потому что тестировать вручную долго и дорого.
Решение: много костылей, регулярные обращения к программистам за помощью.
Впрочем, тесты работают и я многому научился. И мораль моей ретроспективы будет не в том, что не стоит совершать моих ошибок, а в том, что я разобрался со странной и нетипичной задачей — по-своему, но разобрался.
Начну свой рассказ со знакомства с проектом. Это веб-сервис «ВсеПлатежи» [1], с помощью которого люди оплачивают услуги ЖКХ, связи, автомобильные штрафы, делают платежи по кредитам и оплачивают покупки в некоторых интернет-магазинах. Сервис работает с 30 тысячами операторов услуг, это большой продукт со сложной историей, внушительным количеством интеграций и собственной командой.
Компания Лайв Тайпинг [2], где я работаю QA-специалистом, разработала для сервиса кроссплатформенное мобильное приложение [3]. Клиенту нужно было сделать MVP, чтобы проверить ряд гипотез, и «кроссплатформа» была единственным способом быстро и недорого исполнить это желание.
Как я уже сказал выше, сервис живёт сложной и интересной внутренней жизнью. Команда разработки веб-сервиса регулярно вносит в его работу изменения и выкатывает их на сервер два раза в неделю. Наша команда никак не участвует в том, что происходит на бэке, зато участвует в разработке приложения. Мы не знаем, что увидим на экране приложения после очередного релиза и как внесённые изменения повлияют на работу приложения.
Когда речь идёт о работе MVP, то задача-максимум — поддерживать работу одной или нескольких ключевых возможностей продукта. В платежном сервис такими возможностями стали проведение оплаты поставщику услуг, работа корзины и отображение списка поставщиков услуг. Но оплата — важнее прочих.
Чтобы изменения, внесенные разработчиками сайта, не блокировали исполнение ключевых бизнес-кейсов приложения, нужно тестирование. Дымового вполне достаточно: запустилось? не сгорело? отлично. Но с такой частотой релизов тестировать приложение вручную было бы слишком затратно.
В голову пришла гипотеза: а что, если этот процесс автоматизировать? И мы выделили время и бюджет, чтобы автоматизировать ряд ручных тестов и в будущем тратить два часа в неделю на тестирование вместо шести-восьми.
Важно сказать, что изменения в работе сайта касаются не только UI, но и UX. Мы договорились, что аналитик со стороны клиента будет заранее рассказывать нам про планируемые обновления на сайте. Они могут быть разными, от перемещения кнопки до внедрения нового раздела. Тестирование последнего нельзя доверить автоматике — это сложный UX-сценарий, который приходится по старинке находить и проверять руками.
Тестировать основные функции мы решили через интерфейс приложения, вооружившись фреймворком Appium [4]. Appium Inspector запоминает действия с интерфейсом и преобразует их в скрипт, тестировщик запускает этот скрипт и видит результаты теста. Так мы представляли себе работу в начале.
Тут мы ненадолго вернёмся к метафорическому вступлению к моей истории. Чтобы автоматизировать тесты, надо уметь программировать, а тут мои полномочия, как говорится, всё. Введение в этот мир заняло примерно четыре часа: мы развернули и настроили среду, техдир заверил, что всё просто, на примере одного теста показал, как писать остальные, и больше особо в мою работу на проекте не вмешивался. Кинул в воду со спущенным спасательным кругом и отсалютовал.
Я толком не представлял, что получится.
Начал с того, что составил тест-кейсы для проверки оплаты:
Для корзины и списка поставщиков тоже были составлены тест-кейсы. Дальше планировалось перейти к автоматизации других, более сложных сценариев. Но мы отказались от такого плана, потому что видов заполняемых форм у разных поставщиков услуг много. Для каждой из форм пришлось бы делать автоматизированный тест отдельно, а это долго и дорого. Клиент тестирует их сам.
Ещё одно ожидание было таким: раз это автотест, то тест-кейс может быть каким угодно сложным. Ведь программа всё будет тестировать сама, а тестировщику нужно будет только задать последовательность действий. Я придумывал огромные, монструозные кейсы, в которых в цикл оплаты вставлено ещё несколько дополнительных проверок, например таких: что будет, если в оплате перейти из корзины к списку поставщиков, добавить нового, потом вернуться, удалить его и продолжить оплату.
Когда я написал такой тест, я увидел, насколько он огромный и насколько нестабильно работает. Стало понятно, что тест-кейсы нужно упрощать. Короткий тест легче поддерживать и дописывать. И вместо тестов с несколькими проверками я начал делать тесты с одной-двумя проверками.
Что касается софта для тестирования, работу с Appium я представлял так: я совершаю какую-то последовательность действий в рекордере, он это записывает, фреймворк собирает из этого скрипт, я запускаю получившийся код и он повторяет мои действия в приложении.
Звучало неплохо, но только звучало.
И вот с какими проблемами я столкнулся:
В первый раз скрипт выполняет эти действия и у него получается то, что нужно. Но когда вы снова запускаете скрипт, он переключает клавиатуру с кириллицы на латиницу, не может найти на клавиатуре русскую букву и падает. Поэтому скрипту нужно было задавать условия с помощью кода, например, «попытайся найти русскую букву, если ты не можешь, переключи клавиатуру». Вроде бы простая вещь для того, кто давно программирует, но не для меня на тот момент.
Appium может найти элемент по названию, но бывает так, что у элемента даже его нет. Например, в приложении есть корзина, и кнопка корзины обозначена иконкой; она не подписана, у неё нет никакого названия — ничего. И чтобы скрипт её нажал, он должен как-то её найти. Без названия это никак нельзя сделать, даже перебором — скрипту не к чему обратиться и он не может нажать на кнопку корзины. А если бы у корзины был ID, его бы увидел рекордер в процессе записи действий, и скрипт смог бы найти кнопку. Решение нашлось неоднозначное.
В нативной разработке большинству элементов присваивается ID, к которому рекордер обращается без проблем.
Но не стоит забывать, что наш продукт — кроссплатформенное приложение. Их основная особенность в том, что среди нативных элементов присутствует веб-часть, к которой рекордер не может обращаться так же, как к нативной. Он считывает элементы непредсказуемо — где-то текст, где-то тип — и нет никаких специальных ID, т.к. в вебе ID используется для других целей. Проект изначально пишется средствами веб-разработки (то есть на JavaScript), после чего Cordova [5] генерирует нативный код, разный для платформ iOS и Android, и присваивает ID в только ей самой ведомом порядке.
Итак, решение. Так как я мог обращаться к элементам по их названиям, я попросил разработчика задать название кнопкам прозрачным шрифтом. Название есть, пользователь его не видит, но видит рекордер Appium. Скрипт может обратиться к такой кнопке и нажать на неё.
Я в любом случае проверял ошибку вручную. Логи были, в минимальном своём исполнении, но были. И то хорошо.
Сейчас, когда работа над тестами закончена, я смотрю на то, что получилось и думаю: я бы все сделал иначе: там, где рекордер генерирует скрипты, написал бы тесты вручную; добавил бы вставку данных для входа там, где элементы ищутся на клавиатуре; избавился бы от перебора элементов посредством добавления ID; изучил бы фреймворк, запускающий тесты циклом; настроил и подключил бы CI, чтобы тесты сами запускались после каждого деплоя; настроил бы логирование и рассылал бы результаты по почте.
Но тогда я почти ничего не знал и проверял все свои решения, потому что не был в них уверен. Иногда я вообще не представлял, каким оно должно быть.
Тем не менее, я выполнил задачу — на проекте появились автотесты, и мы смогли проверять работу приложения на фоне постоянных изменений. К тому же, наличие тестов избавило от необходимости сидеть и протыкивать одни и те же сценарии два раза в неделю, что занимает очень много времени при ручном тестировании, ведь каждый сценарий повторяется 100 раз. А я получил мощный опыт и понимание того, как на самом деле нужно было всё это сделать. Если вам есть что посоветовать или добавить к сказанному выше, буду рад продолжить беседу в комментариях.
Автор: execut1oner
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/278372
Ссылки в тексте:
[1] «ВсеПлатежи»: https://livetyping.com/ru/portfolio/vseplatezhi
[2] Лайв Тайпинг: https://livetyping.com/en/
[3] кроссплатформенное мобильное приложение: https://livetyping.com/ru/blog/cross-platform-vs-native-apps-comparing-and-selecting-approaches
[4] Appium: http://appium.io/
[5] Cordova: https://cordova.apache.org
[6] Источник: https://habrahabr.ru/post/353962/?utm_campaign=353962
Нажмите здесь для печати.