Embed Size (px)
Citation preview
Как мы автоматизируем UI-тестирование
в iOS Почте Mail.Ru
Алексей Халайджи
Отдел iOS разработки Почты Mail.Ru
О докладчике
• Алексей Халайджи
• Закончил МГТУ им. Н.Э. Баумана (ИУ-6)
• Закончил Технопарк Mail.Ru
• Работаю в Mail.Ru с января 2015 года
• Занимаюсь автоматизацией UI-тестирования с лета 2015 года
Расскажу о…
• Роль автоматизированного тестирования в процессе разработки
• Фреймворк для тестирования
• Первоначальное состояние у истоков автоматизации
• История развития нашей инфраструктуры тестирования
• Проблемы при автоматизации и их решения
• Результаты
Часть 1. Введение. О структуре и процессах
Роль автоматизированного тестирования
• Снижение нагрузки на команду ручного тестирования
• Проверка всей основной функциональности приложения после каждого изменения проекта
• Замещение ручного регрессионного тестирования
• Устранение повторяющихся багов
Автоматизированное тестирование в Workflow • Задачи в jira для обычных задач • Отдельный Workflow для интеграции с QA-отделом • Возможные стейты задач:
• TO AUTOMATE – при создании. Присутствует описание тест-кейса. Ожидает аппрува команды автоматизации тестирования
• WAITING FOR AUTOMATION – аппрув получен, ожидает автоматизации • IN PROGRESS – ТК находится в процессе автоматизации • AUTOMATED READY – ТК автоматизирован • WON’T BE AUTOMATED – ТК не будет автоматизирован
• Связь с обычными задачами через ссылки • Связь с автоматизированными тестами через ссылки и автоматически
генерируемую документацию
Часть 2. Фреймворк для тестирования
Мы используем MonkeyTalk
• Наиболее стабильный
• Возможность доработки функционала
• Нет более подходящих альтернатив
• BDD
• Есть визуальная IDE с возможностью записи действий пользователя
Компоненты MonkeyTalk
• IDE
• Java-обработчик команд
• Статическая библиотека с прослушивающим команды веб-сервером
Особенности синтаксиса
• BDD
• Вид команды: • <Тип компонента> <Идентификатор> <Действие> [<Аргументы>
<Модификаторы>]
• Напр., Button Login_button Tap View Hello_user WaitFor 25 %thinktime=5000
• Вызов кода приложения • App MRUITHelper Exec stubMethod
• App MRUITHelper ExecAndReturn result getResultForString “string”
Первоначальное состояние у истоков автоматизации • ТК пишет команда QA
• Автоматизация тестов через IDE+record
• Автоматизация разработчиками и отделом QA
• В результате: ~50 UI-тестов, выполняемых за 1.5 часа
Часть 3. О проблемах, или с чем мы столкнулись
1. Общие проблемы
• Мало документации
• Мало примеров
• Все баги и улучшения приходится допиливать самим
• Мало обсуждений на stackoverflow.com
• Нет поддержки с лета 2015 года
”I got a new master now…”
- The Genie
Но…
• Мы имеем доступ к открытому коду MonkeyTalk
• Сами можем править баги
• Можем дописывать новый функционал
• Не зависим от других разработчиков
• Быстрая реакция на возникающие проблемы
2. Локализация
• IDE использует надписи на элементах, напр.: Button “Sign In” Tap
• Не устойчиво к смене языка на симуляторе
• Не устойчиво к смене перевода локализуемой строки
• Изменение перевода ведёт к изменению команды во всех тестах
Использование идентификаторов
• Использование accessibilityIdentifier вместо строк, напр.: Button [signin-button] Tap
• Проверка локализации через хелперы, напр.: App LocalizationHelper ExecAndReturn localizedText localizedStringForId sign_in_button_text Button [signin-button] Verify ${localizedText} .text
Задумайтесь над локализацией ЗАРАНЕЕ!!!
3. Нестабильное прохождение тестов
• Нестабильность может быть вызвана: • Долгая загрузка симулятора
• Долгий старт приложения на симуляторе
• «Тормоза» тестирующей машины
• Долгая загрузка тела письма при прочтении
• Использование хелперов без ожидания
• …
• Много повторов тестов
• Много false-negative результатов
Повышение стабильности
• Ручное выставление задержек (не круто!)
• Привязка по возможности к элементам (напр., ProgressHUD)
• Патчинг MonkeyTalk для ожидания элементов при вызове хелперов, напр.: App ExecAndReturn result validateView [emails][0] %waitfor=[folderTitle]
4. Очень долгое выполнение всех тестов
• ~ 100 тестов
• 3 часа на одной машине
Снижение времени ожидания
• Разделение на папки по функциональности (напр., auth, compose, …)
• Примерно одинаковое число тестов в папке
• Упал один тест категории – остальные не запускаем
• Запуск категорий на отдельных машинах
• Система нотификаций: • Упала категория -> сообщение об ошибке категории • Все категории прошли -> Сообщение об успехе прохождения тестов
• Результат: параллельное выполнение 5-6 категорий по 20 тестов за 40 минут
5. Взаимодействие с iOS
• Контроль запуска и очистки симулятора
• Контроль запуска приложения
• Последовательное увеличение таймаута запусков
• Влияние на запуск приложения (например, по пушу)
• Сворачивание и перезапуск приложения
Блок описания теста
• В каждом тесте есть блок док. описания. Он состоит из следующих пунктов: • Обязательные
• Tasks – списки jira id задач • Name - название теста • Сategory – название категории • Description – краткое описание теста
• Необязательные • Args – аргументы • Utils – аргументы для инфраструктуры запуска тестов • Runtime – версия ОС, на которой нужно запускать тест
• По описанию автоматически может быть сгенерирована документация • Проверка наличия всех обязательных блоков проводится
автоматически
Влияние на запуск приложения
• С помощью аргументов
• В приложении есть хелпер для работы с аргументами запуска приложения
• В load методах необходимая функциональность включается/эмулируется
• Так же может быть использован method swizzling (то есть замена реализации метода для его сигнатуры).
Suite
• Отличается от suite в привычном понимании MT – это не последовательность
• MT Suite – это совокупность тестов, выполняемых последовательно вне зависимости от результата их выполнения с формированием общего отчёта
• MT Suite реализован нами в общей инфраструктуре запуска тестов • Suite – последовательность тестов:
• Требующих перезапуска приложения • При падении одного теста перезапускается весь suite целиком • Есть отдельный файл описания docs_suite • Есть наследование аргументов из docs_suite в тестах suite • Перезапуск приложения реализован через перезапуск симулятора без его
очистки
Перезапуск и сворачивание/разворачивание приложения
• Перезапуск реализован через suite
• Для сворачивания/разворачивания приложения и ряда других функций используем private API
• Так как тестовая сборка собирается только локально и никуда не отправляется, то private API использовать можно
• Патчинг MT, чтобы принимающий сервер библиотеки не останавливался при сворачивании приложения
• Пример вызовов из тестов: App MRUITHelper Exec suspendApp App MRUITHelper Exec wakeApp
6. Повторное использование кода
• Много тестов имеют одинаковые участки кода, например авторизацию
• MT позволяет запускать отдельные файлы как команду. Например: Script Login.mt Run login password
• При иерархической структуре файлов тестов требуется много симлинков
• Не хватает стандартного механизма запуска отдельных тестов как команд
Повторное использование кода
Использование JS
• Помимо BDD-описания тестов MT позволяет использовать JS
• Возможность создания библиотеки для обработки конкретных элементов
• Использование Page Object подхода
• Использование возможностей языка: ООП, циклы, функции…
7. Работа с сетью
• Одно из требований к тестам - изолированность • Тесты не могут влиять на исполнение друг друга
• При работе с сетью меняется состояние на сервере, напр. прочитанность письма
• Если тест упал, но не вернул состояние сервера, то он влияет на остальные тесты
• Тесты разных задач выполняются параллельно на разных машинах
Стаббинг сетевых запросов
Стаббинг сетевых запросов
• Использование NSURLProtocol для перехватывания запросов по определённым URL
• Работа через IMAP реализована через специальный прокси
• Возможности: • Добавление обработчиков с помощью хелперов из теста • Подмена ответов на сетевые запросы • Проверки наличия запросов и их количества • Добавление обработчиков с помощью аргументов запуска теста (напр,
для эмуляции отсутствия сети) • Возможность добавления фильтров на IMAP-запросы в прокси из теста и
через аргументы
8. Запуск тестов для разных почтовых протоколов • Задача:
• Есть ~250 тестов • Они работают по JSON API через NSURLProtocol • Множество тестов нужно запускать также и на IMAP
• Решение: • Используется специальный аргумент в док. описании теста alt_args_cases • Позволяет запускать один и тот же тест с каждым из параметров из
набора • Эти аргументы совмещаются с args • Для IMAP-тестов можно добавить аргумент IMAPMode и обрабатывать
его отдельно в хелперах • Тесты расширить добавлением фильтров для IMAP-прокси
9. Всё равно очень долго
• Категорий около 15
• Машин около 8
• Всего тестов около 300
• Суммарное время тестирования одной задачи без очередей на машины ~2 часа
Распараллеливание запуска тестов на одной машине • Для каждого теста с аргументами создаётся свой уникальный id и
симулятор
• Задаётся максимальное количество одновременно запускаемых симуляторов
• Каждый симулятор запускает MT-сервер на отдельном порту
Разбиение тестов по машинам
• Использование вместо папок тегов из док. описания для деления тестов на группы
• Использование статистики времени выполнения тестов для разделения тестов на группы, выполняющиеся на разных машинах
• Выполняются все тесты вне зависимости от падения одного в группе
• Новая система нотификаций • Результаты всех групп объединяются
• Формируется общий отчёт
• Разработчикам приходит нотификация со ссылкой на отчёт
• В результате: 400 тестов за 45 минут
Часть 4. Результаты автоматизации за год
• От 50 нестабильных тестов за 90 минут
• До 400 стабильных за 45 минут
• Система нотификаций
• Композитная инфраструктура управления запуском тестов и групп тестов (suite)
• Статистика выполнения тестов
• Библиотека Page Object-ов и общих JS-функций и ObjC-хелперов
Результаты автоматизации за год
