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

1. Как мы автоматизируем
UI-тестирование
в iOS Почте Mail.Ru
Алексей Халайджи
Отдел iOS разработки Почты Mail.Ru

2. О докладчике
• Алексей Халайджи
• Закончил МГТУ им. Н.Э. Баумана (ИУ-6)
• Закончил Технопарк Mail.Ru
• Работаю в Mail.Ru с января 2015 года
• Занимаюсь автоматизацией
UI-тестирования с лета 2015 года

3. Расскажу о…
• Роль автоматизированного тестирования в процессе разработки
• Фреймворк для тестирования
• Первоначальное состояние у истоков автоматизации
• История развития нашей инфраструктуры тестирования
• Проблемы при автоматизации и их решения
• Результаты

4. Часть 1.
Введение.
О структуре и процессах

5. Роль автоматизированного тестирования
• Снижение нагрузки на команду ручного тестирования
• Проверка всей основной функциональности
приложения после каждого изменения проекта
• Замещение ручного регрессионного тестирования
• Устранение повторяющихся багов

6. Автоматизированное тестирование в
Workflow
• Задачи в jira для обычных задач
• Отдельный Workflow для интеграции с QA-отделом
• Возможные стейты задач:
• TO AUTOMATE – при создании. Присутствует описание тест-кейса. Ожидает
аппрува команды автоматизации тестирования
• WAITING FOR AUTOMATION – аппрув получен, ожидает автоматизации
• IN PROGRESS – ТК находится в процессе автоматизации
• AUTOMATED READY – ТК автоматизирован
• WON’T BE AUTOMATED – ТК не будет автоматизирован
• Связь с обычными задачами через ссылки
• Связь с автоматизированными тестами через ссылки и автоматически
генерируемую документацию

7. Часть 2.
Фреймворк для тестирования

8. Мы используем MonkeyTalk
• Наиболее стабильный
• Возможность доработки функционала
• Нет более подходящих альтернатив
• BDD
• Есть визуальная IDE с возможностью записи
действий пользователя

9. Компоненты MonkeyTalk
• IDE
• Java-обработчик команд
• Статическая библиотека с прослушивающим команды веб-
сервером

10. Особенности синтаксиса
• BDD
• Вид команды:
• <Тип компонента> <Идентификатор> <Действие> [<Аргументы>
<Модификаторы>]
• Напр.,
Button Login_button Tap
View Hello_user WaitFor 25 %thinktime=5000
• Вызов кода приложения
• App MRUITHelper Exec stubMethod
• App MRUITHelper ExecAndReturn result getResultForString “string”

11. Первоначальное состояние у истоков
автоматизации
• ТК пишет команда QA
• Автоматизация тестов через IDE+record
• Автоматизация разработчиками и отделом QA
• В результате: ~50 UI-тестов, выполняемых за 1.5 часа

12. Часть 3.
О проблемах, или с чем мы
столкнулись

13. 1. Общие проблемы
• Мало документации
• Мало примеров
• Все баги и улучшения приходится допиливать самим
• Мало обсуждений на stackoverflow.com
• Нет поддержки с лета 2015 года
”I got a new master now…”
- The Genie

14. Но…
• Мы имеем доступ к открытому коду MonkeyTalk
• Сами можем править баги
• Можем дописывать новый функционал
• Не зависим от других разработчиков
• Быстрая реакция на возникающие проблемы

15. 2. Локализация
• IDE использует надписи на элементах, напр.:
Button “Sign In” Tap
• Не устойчиво к смене языка на симуляторе
• Не устойчиво к смене перевода локализуемой строки
• Изменение перевода ведёт к изменению команды во всех тестах

16. Использование идентификаторов
• Использование accessibilityIdentifier вместо строк, напр.:
Button [signin-button] Tap
• Проверка локализации через хелперы, напр.:
App LocalizationHelper ExecAndReturn localizedText
localizedStringForId sign_in_button_text
Button [signin-button] Verify ${localizedText} .text

17. Задумайтесь над локализацией
ЗАРАНЕЕ!!!

18. 3. Нестабильное прохождение тестов
• Нестабильность может быть вызвана:
• Долгая загрузка симулятора
• Долгий старт приложения на симуляторе
• «Тормоза» тестирующей машины
• Долгая загрузка тела письма при прочтении
• Использование хелперов без ожидания
• …
• Много повторов тестов
• Много false-negative результатов

19. Повышение стабильности
• Ручное выставление задержек (не круто!)
• Привязка по возможности к элементам (напр., ProgressHUD)
• Патчинг MonkeyTalk для ожидания элементов при вызове
хелперов, напр.:
App ExecAndReturn result validateView [emails][0]
%waitfor=[folderTitle]

20. 4. Очень долгое выполнение всех тестов
• ~ 100 тестов
• 3 часа на одной машине

21. Снижение времени ожидания
• Разделение на папки по функциональности
(напр., auth, compose, …)
• Примерно одинаковое число тестов в папке
• Упал один тест категории – остальные не запускаем
• Запуск категорий на отдельных машинах
• Система нотификаций:
• Упала категория -> сообщение об ошибке категории
• Все категории прошли -> Сообщение об успехе прохождения тестов
• Результат: параллельное выполнение 5-6 категорий по 20 тестов
за 40 минут

23. 5. Взаимодействие с iOS
• Контроль запуска и очистки симулятора
• Контроль запуска приложения
• Последовательное увеличение таймаута запусков
• Влияние на запуск приложения (например, по пушу)
• Сворачивание и перезапуск приложения

24. Блок описания теста
• В каждом тесте есть блок док. описания. Он состоит из следующих
пунктов:
• Обязательные
• Tasks – списки jira id задач
• Name - название теста
• Сategory – название категории
• Description – краткое описание теста
• Необязательные
• Args – аргументы
• Utils – аргументы для инфраструктуры запуска тестов
• Runtime – версия ОС, на которой нужно запускать тест
• По описанию автоматически может быть сгенерирована документация
• Проверка наличия всех обязательных блоков проводится
автоматически

25. Влияние на запуск приложения
• С помощью аргументов
• В приложении есть хелпер для работы
с аргументами запуска приложения
• В load методах необходимая
функциональность включается/эмулируется
• Так же может быть использован method swizzling
(то есть замена реализации метода для его сигнатуры).

26. Suite
• Отличается от suite в привычном понимании MT – это не
последовательность
• MT Suite – это совокупность тестов, выполняемых последовательно вне
зависимости от результата их выполнения с формированием общего
отчёта
• MT Suite реализован нами в общей инфраструктуре запуска тестов
• Suite – последовательность тестов:
• Требующих перезапуска приложения
• При падении одного теста перезапускается весь suite целиком
• Есть отдельный файл описания docs_suite
• Есть наследование аргументов из docs_suite в тестах suite
• Перезапуск приложения реализован через перезапуск симулятора без его
очистки

27. Перезапуск и сворачивание/разворачивание
приложения
• Перезапуск реализован через suite
• Для сворачивания/разворачивания приложения и ряда других
функций используем private API
• Так как тестовая сборка собирается только локально и никуда не
отправляется, то private API использовать можно
• Патчинг MT, чтобы принимающий сервер библиотеки не
останавливался при сворачивании приложения
• Пример вызовов из тестов:
App MRUITHelper Exec suspendApp
App MRUITHelper Exec wakeApp

28. 6. Повторное использование кода
• Много тестов имеют одинаковые участки кода, например
авторизацию
• MT позволяет запускать отдельные файлы как команду.
Например:
Script Login.mt Run login password
• При иерархической структуре файлов тестов требуется много
симлинков
• Не хватает стандартного механизма запуска отдельных тестов как
команд

29. Повторное использование кода

30. Использование JS
• Помимо BDD-описания тестов MT позволяет использовать JS
• Возможность создания библиотеки для обработки конкретных
элементов
• Использование Page Object подхода
• Использование возможностей языка: ООП, циклы, функции…

31. 7. Работа с сетью
• Одно из требований к тестам - изолированность
• Тесты не могут влиять на исполнение друг друга
• При работе с сетью меняется состояние на
сервере, напр. прочитанность письма
• Если тест упал, но не вернул состояние сервера, то он влияет на
остальные тесты
• Тесты разных задач выполняются параллельно
на разных машинах

32. Стаббинг сетевых запросов

33. Стаббинг сетевых запросов
• Использование NSURLProtocol для перехватывания запросов по
определённым URL
• Работа через IMAP реализована через специальный прокси
• Возможности:
• Добавление обработчиков с помощью хелперов из теста
• Подмена ответов на сетевые запросы
• Проверки наличия запросов и их количества
• Добавление обработчиков с помощью аргументов запуска теста (напр,
для эмуляции отсутствия сети)
• Возможность добавления фильтров на IMAP-запросы в прокси из теста и
через аргументы

34. 8. Запуск тестов для разных почтовых
протоколов
• Задача:
• Есть ~250 тестов
• Они работают по JSON API через NSURLProtocol
• Множество тестов нужно запускать также и на IMAP
• Решение:
• Используется специальный аргумент в док. описании теста alt_args_cases
• Позволяет запускать один и тот же тест с каждым из параметров из
набора
• Эти аргументы совмещаются с args
• Для IMAP-тестов можно добавить аргумент IMAPMode и обрабатывать
его отдельно в хелперах
• Тесты расширить добавлением фильтров для IMAP-прокси

35. 9. Всё равно очень долго
• Категорий около 15
• Машин около 8
• Всего тестов около 300
• Суммарное время тестирования одной
задачи без очередей на машины ~2 часа

36. Распараллеливание запуска тестов на
одной машине
• Для каждого теста с аргументами создаётся свой уникальный id и
симулятор
• Задаётся максимальное количество одновременно запускаемых
симуляторов
• Каждый симулятор запускает MT-сервер на отдельном порту

37. Разбиение тестов по машинам
• Использование вместо папок тегов из док. описания для деления
тестов на группы
• Использование статистики времени выполнения тестов для
разделения тестов на группы, выполняющиеся на разных машинах
• Выполняются все тесты вне зависимости от падения одного в группе
• Новая система нотификаций
• Результаты всех групп объединяются
• Формируется общий отчёт
• Разработчикам приходит нотификация со ссылкой на отчёт
• В результате: 400 тестов за 45 минут

38. Часть 4.
Результаты автоматизации за
год

39. • От 50 нестабильных тестов за 90 минут
• До 400 стабильных за 45 минут
• Система нотификаций
• Композитная инфраструктура управления запуском тестов и групп
тестов (suite)
• Статистика выполнения тестов
• Библиотека Page Object-ов и общих JS-функций и ObjC-хелперов
Результаты автоматизации за год

40. Спасибо за внимание
Алексей Халайджи
Отдел iOS разработки Почты Mail.Ru
a.halaidzhy@corp.mail.ru