Ios тестирование: Apple Beta Software Program

Содержание

Тестирования IOS приложений — Getbug

Заказывая тестирование мобильного приложения на платформе iOS, в результате вы хотите получить стабильное и надежное приложение. Мы подготовили чек лист тестирования приложения на IOS, без которого нельзя отдавать приложение в стор, а тем более на iPhone клиента.

Безопасность

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

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

Проверка возможности перехватить снифферами входящие или исходящие данные. Эта проверка может проводится для банковского ПО или корпоративных приложений, работающих по протоколу https, и имеющих высокие требования к политики безопасности.
Проверка безопасности передачи данных между приложениями по Wi-Fi. В процессе возникает опасность уязвимости к атакам типа MITM (перехват данных).

Тестируя разработку iPhone приложения с помощью расширения FireSheep, можно выполнять проверку вероятности кражи данных в сессии пользователя, проверять наличия не защищенной конфиденциальной информации в сессиях.

In-App Purchase (Покупки в приложении)

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

Правила использования IAP:

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

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

Типы подключений

Основные виды интернет соединения:

Сотовая связь для передачи данных: 2G, 2.5G, 3G, 4G;
Wi-Fi;
Mi-Fi – точка для передачи интернета, который был получен по сотовой связи.

Большинство смартфонов используют современные технологии для передачи мобильного трафика. С помощью настроек устройства можно получить доступ к типу устанавливаемого соединения (2G/3G/4G). Стоит отметить, что наложение ограничений связи касается не только мобильного трафика, но и Wi-Fi.

Тестирование на различных скоростях передачи данных

Использование симуляторов/эмуляторов;
Сторонняя прошивка роутера;
Стороннее ПО (прокси).

Переключение типов соединения и отсутствие связи:

Что можно проверить в iOS приложениях? Например:

Выдвинуть «шторку» в нижней части и включить режим полета либо выключить Wi-Fi.
Выключить или перезагрузить точку доступа, тем самым отключив мобильный трафик.
Можно использовать роутер или «шторку», чтобы переключаться между видами связи. Обычно, настройки операционной системы позволяют при наличии сильного источника сигнала переключаться автоматически. Например:

Переключение приложения на мобильный трафик (2G/2.5G/3G/4G) при выключении Wi-Fi;
Автоматическое переключение на Wi-Fi при его включении и нахождении нужной сети.

Публичные сети с авторизацией

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

Web-аутентификация сразу после установки Wi-Fi соединения. Данный тип подключения не дает право на доступ к сервисам, отличающихся от начального;
Подключение к локальной сети роутера через привязку к MAC-адресу устройства. Данный тип соединения дает возможность подключения к Wi-Fi, однако ограничивает доступ к пользованию интернетом;
Переход на Web аутентификацию при отправке запроса на любой публичный адрес.

Ресурсы устройства

Обязательна нужно проверять обработку в следующих ситуациях:

Не хватает места в памяти при установке или работе. Приложение должно показывать понятное уведомление с информацией. Приложения не должно просто падать.

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

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

Например, вы находитесь в неизвестном городе, и скачиваете навигатор или гид по этому городу. После запуска, приложение закрывается без уведомлений, вместо корректного уведомления о недостаточном объеме памяти для корректного запуска. Скорее всего, вы сразу удалите приложение и поищите что то еще. Если бы вы увидели понятное уведомление, то просто удалили бы пару ненужных приложений и спокойно перезапустили навигатор или гид.

Разрядка батареи

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

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

Работа с прерываниями

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

Тестирование размера экрана

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

Сворачивание/разворачивание активного приложения

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

Резюме

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

«Life.ru» — информационный портал

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

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

Перейдите по ссылке с мобильного устройства и загрузите профиль конфигурации.

Перед вами появится окно об открытии настроек. Нажмите «Разрешить» и дождитесь автоматического закрытия окна.

Пройдите по «Настройки» —> «Основные» —> «Профиль», выберите строку iOS 14 Beta Software Profile и нажмите «Установить». Подтвердите действие вводом ПИН-кода. Ещё раз подтвердите установку профиля конфигурации и согласитесь на перезагрузку устройства.

Когда устройство перезагрузится, пройдите по «Настройки» —> «Основные» —> «Обновление ПО» и начните загрузку iOS 14 Developer beta.

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

Спасение от бед — резервная копия. Она создаётся следующим образом:

Подключите устройство к сети Wi-Fi. Пройдите по «Настройки» —> «Аккаунт» —> iCloud —> «Копия iCloud». Нажмите «Создать резервную копию». Не отключайтесь от сети Wi-Fi до завершения процесса.

После этого можете устанавливать бета-версию. Ваши данные останутся в сохранности, и вы в любой момент сможете восстановить их.

Для этого вам понадобится подключение к компьютеру на macOS или Windows.

Вот как это сделать на macOS:

А так можно откатиться на Windows:

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

Делается это следующим образом:

Производительность iOS 14 по сравнению с iOS 13, iOS 12, iOS 11 в видео-тесте | Смартфоны | Дайджест новостей

https://c.dns-shop.ru/thumb/st1/fit/760/456/b37d54ac6bb2ae59e1f27780d726758c/q93_770aa5e8aa92669f4a87b6d3bb209c14ed803c33a258496f749faec2004b5f16.jpg Производительность iOS 14 по сравнению с iOS 13, iOS 12, iOS 11 в видео-тесте Производительность iOS 14 по сравнению с iOS 13, iOS 12, iOS 11 в видео-тесте 2020-09-19T18:56:45+00:00 2020-09-19T18:56:45+00:00 2020-09-19T18:56:45+00:00 Cabbage1862

Apple

Операционная система

ios 14

программное обеспечение

Клуб DNS

https://club.dns-shop.ru/images/club-logo.png

Производительность iOS 14 по сравнению с iOS 13, iOS 12, iOS 11 в видео-тесте

iOS 14 наконец-то выпущена для широкой публики, и она приносит множество новых дополнений.

Одно из самых заметных и значительных изменений, это появление виджетов на главном экране. Однако важно было бы спросить о производительности iOS 14 по сравнению с iOS 13, iOS 12, iOS 11 и даже iOS 10. Если вам интересно, посмотрите новое видео теста скорости iOS 14.

Ранее, да и сейчас, бытует мнение, что компании специально замедляют работу смартфонов при каждом крупном обновлении программного обеспечения. Apple однажды даже обвинили в замедлении работы iPhone, которое она исправила еще в 2018 году с помощью iOS 12. Имея в виду подобные случаи, YouTube iAppleBytes сделал видео для проверки скорости iOS 14, в котором сравнивается последняя операционная система с iOS 13, iOS 12, iOS 11, и даже iOS 10.

Удивительно, но производительность iOS 14 находится на одном уровне с iOS 12 и iOS 13, что видно из видео теста скорости. Разницы в производительности нет, и это большой плюс для новой сборки. Оценки Geekbench также очень похожи, как и время загрузки приложений. Стоит обратить внимание на то, что видео для тестирования скорости iOS 14 было снято с финальной стабильной сборкой iOS 13, iOS 12, iOS 11 и iOS 10. Поскольку iOS 14 является новой, Apple продолжит оптимизацию и исправит ошибки в следующих обновлениях. Это потенциально может повысить производительность, но делать окончательные выводы еще рано.

Источник: wccftech

Бета-тестирование iPhone-приложений / Хабр

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

Ни для кого не секрет, что бета-тестирование на смартфонах — довольно трудоемкий процесс, а уж на iPhone — и подавно. Все дело в его многоступенчатости: сперва пользователю нужно найти UDID своего устройства, затем отправить его разработчикам. Только после этих действий со стороны юзера его аппарат вносится в список зарегистрированных девайсов, а уж потом собирается рабочая версия и отсылается ему на почту письмо с просьбой об установке.

Но и это еще не все. Пользователь заходит в iTunes, инсталлирует приложение и только после всех вышеперечисленных операций оно оказывается на его устройстве. Вам не кажется, что вся эта цепочка действий слишком сложна? Далеко не каждый захочет заморачивать себе голову. И уж тем более отсылать вам feedback вручную (автоматизированно это никак нельзя сделать), а если даже и будет, то его качество скорее всего не будет таким же хорошим по нескольким причинам: пользователь просто может забыть где им была найдена ошибка, не понять в каком месте произошло крушение приложения, не запомнить, что именно ему не понравилось на каком-либо из экранов, неверно указать на подтормаживания и лаги, ну и конечно неправильно оценить то, что просто отказывалось работать. Так как же решить эту проблему?

На помощь нам приходит один умный сервис: TestFlightApp.com. Он служит для упрощения процесса бета-тестирования и, как это ни парадоксально, сам недавно находился в стадии тестирования, но сейчас функционирует на полной мощности.

Начать работать с ним очень просто. Регистрируем свой проект и нажимаем на кнопку «пригласить тестеров». Все, что от них требуется — это адрес почтового ящика, на который придет приглашение принять участие в тестировании. Пользователи открывают это письмо на своем iPhone и разработчикам приходит UDID их устройства, а юзер заносится в список. Однако есть одно «но»: привязку UDID к вашему аккаунту в iTunesconnect невозможно автоматизировать, поэтому этот шаг приходится делать вручную. Правда, это совсем не страшно и не требует большого количества времени. Так что поводов для беспокойства нет.

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

1. Sessions
Очень полезная штука. Никакой мороки и «ручного» feedback. Просто заходим туда и смотрим как пользователи используют приложение, куда они заходят и сколько времени они проводят за его тестированием. Все полностью автоматизировано. Теперь не нужно ждать весточки от добрых людей, которые действительно решили вам помочь и отписаться о найденных ошибках.

2. In-App Questions

Тоже интересная вещь. Ставим checkpoints в разных местах и привязываем к каждому определенный вопрос, ответ на который волнует ваши умы. Как только checkpoint пройден пользователем, вылезает окно с вопросом, на который можно быстро ответить. Вообще их существует три типа: ответ да/нет, выбор из множества вариантов и ответ, вписываемый пользователем. Также в новый build можно сделать импорт вопросов из старой версии приложения на случай, если вам лень набирать текст заново.

3. Remote Logging

Польза логов очевидна, так что особых пояснений не требуется. А их удаленное использование еще больше все упрощает: можно легко отследить, что тестер добрался до какого-то момента в сценарии работы приложения, а потом посмотреть где он запнулся. Внедрить в приложение log очень легко, для этого достаточно использовать всем известную директиву #define и использовать стандартный NSLog как и при обычной разработке приложения. Все логи отправляются на сервер асинхронно и не блокируют приложение.

4. Crash report
С помощью этой функции можно получить отчет о падении приложения в реальном времени. Если у пользователя возникли сложности, вы узнаете об этом незамедлительно.

5. Checkpoints
Ставим чекпоинты в разные места и следим, куда попадают тестеры. Таким образом, можно проанализировать какие features в приложении пользуются большей популярностью, а какие требуют доработки. Несомненно, это очередной плюс данного сервиса. Очень удобно использовать checkpoints вкупе с In-App Questions: после прохождения очередной контрольной точки пользователю показывается экран, например, с просьбой оценить насколько хорошо был реализован тот или иной момент.

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

Все еще не верите в работоспособность этого сервиса? Тогда для сравнения попробуйте провести два отдельных бета-тестирования и сравните результат и КПД, полученный от них. Уверяю вас, вы будете приятно удивлены. Главное преимущество здесь — это минимум операций и затрат времени, а также максимальный выхлоп, который вы получите от ваших действий. Думаю, оно того стоит, ведь качественный и своевременный feedback — гарантия успешного продвижения ваших приложений.

Как установить бета-версию iOS 14 уже сейчас. 3 простых шага

Перейдите по ссылке с мобильного устройства и загрузите профиль конфигурации.

Спасение от бед — резервная копия. Она создаётся следующим образом:

Для этого вам понадобится подключение к компьютеру на macOS или Windows.

Вот как это сделать на macOS:

А так можно откатиться на Windows:

Делается это следующим образом:

Современный подход к тестированию локализации на iOS / Блог компании Exness / Хабр

Привет! Давайте поговорим о том, как сейчас в 2020-ом году можно протестировать мультиязычное iOS приложение, если не хочется проверять локализацию вручную.

Мы — финтех-компания, и наша прибыль напрямую зависит от объема торгов. Чем больше наши клиенты открывают ордеров (или сделок), тем больше прибыли получаем мы. А количество сделок напрямую зависит от депозитов: чем больше депозитов, тем больше ордеров может открыть клиент и, соответственно, на больший объем. Но в разных странах удельный размер депозитов сильно различается. Например, в Таиланде в четыре раза больше пользователей, чем во Вьетнаме, но по депозитам этого не скажешь.

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

Мы провели эксперимент: перевели названия, и после релиза количество депозитов возросло в разы.

То есть перевод 6-7 строчек текста на нужный язык в нужном месте может принести очень большую выгоду.

Наше приложение

Немного расскажу о нашем приложении Exness Mobile Trader.

Это личный кабинет трейдера, в котором мы сделали свой собственный торговый терминал на WebSocket. Приложение умеет работать с большим количеством международных и региональных платёжных систем. Есть много преднастроенных сервисов, которые позволяют пользователю торговать эффективнее. Также приложение поддерживает несколько типов счетов: реальные счета с настоящими деньгами, демо-счета для тренировки и крипту. Вишенка на нашем торте — это гибкая система push-уведомлений.

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

В начале 2017 года мы поняли, что 70% пользователей нашей торговой системы заходят в свой личный веб-кабинет через мобильные браузеры, то есть через телефоны и планшеты. И мы решили создать свое мобильное приложение. Сделали пробную версию, но она оказалась неудачной. А в сентябре 2017-го начали работать над основным приложением. Работа заняла год. Мы экспериментировали. Например, в тестировании пробовали BDD-подход, автоматизировали API в Postman. К сентябрю 2018 года был запланирован релиз, и где-то за пару месяцев до этого встал вопрос локализации, так как у нас очень много клиентов по всему миру.

Локализация

Локализация — это процесс адаптации и интернационализации под конкретный регион. Добавление специализированных компонентов, характерных для определенной локали, и перевод текста.

Первая проблема — как оперативно перевести мобильное приложение на несколько языков за короткий срок, когда у тебя разработчики сидят на Кипре, а переводчики в Азии за пять часовых поясов?

Нашим решением стал Crowdin — система управления мультиязычным контентом. Это огромный комбайн, в котором как в Jira, заводишь задачи и распределяешь по всевозможным исполнителям: переводчикам, менеджерам, тестировщикам. Можно голосовать за понравившийся перевод, оставлять комментарии. Благодаря этому инструменту мы довольно быстро перевели приложение на разные языки.

Crowdin всеядный: ему можно скормить XML, так YML, JSON, строки. Он всё распарсит и будет с этим работать. Он не позволяет переводчикам что-то поломать: ~~мухи~~ строки отдельно, код отдельно. У Crowdin крутой API. Можно чуть ли на каждый коммит повесить создание новой задачи на перевод. Инструмент очень гибкий, позволяет работать как с целым файлом для какого-то языка под определенную фичу, так и с отдельными строками. Можно быстро посмотреть, как эта строчка переведена на родственные языки, это актуально, например, для китайского.

А недостаток Crowdin в его довольно высокой стоимости.

После перевода возникла новая проблема: как всё это быстро загрузить и проверить?

В этом помог LinguanApp — «умный» редактор строк в Xcode-проекте, отображающий их в более-менее удобоваримом виде. Он позволяет посмотреть, как выглядят строчки на разных языках, и тут же что-то подправить. Реализована обратная совместимость: сделанные изменения отображаются во взаимосвязанных локациях. В LinguanApp есть удобная функция автоматической валидации: после загрузки всех данных система проверяет, где и что не подгрузилось. Благодаря знакомому, экселеподобному интерфейсу, этот инструмент отлично подходит для управления процессом локализации.

Недостатки: LinguanApp тоже стоит денег, но не так много, как Crowdin.

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

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

Какие сложности могут возникнуть при ручном тестировании локализации? Чтобы пользователю было удобно пользоваться вашим приложением, нужно проверить, как оно выглядит при всех поддерживаемых вами разрешениях экранов и на всех языках, которых может быть очень много: наше приложение кроме английского переведено еще на 14 языков. У одного только iPhone сейчас шесть размеров экранов (если говорить о телефонах, начиная от iPhone SE), итого 6 х 15 = 90 комбинаций «язык — разрешение». Вручную это проверить практически нереально. Хотя изначально мы выпустили приложение только на двух языках, так что протестировать его вручную ещё можно было. Но даже тогда у нас возникли трудности.

Во-первых, у нас не было всех видов устройств: на момент релиза приложения ещё отсутствовал в продаже iPhone Xs Max, а в наличии у нас были только iPhone X, 6S и 6 plus. Конечно, можно было пользоваться симулятором, но это не очень хороший вариант. Мы решили воспользоваться функцией Display Zoom:

В чем суть? Вы можете задать у себя разрешение другого смартфона, картинка и текст станут крупнее. Эта функция появилась в iPhone 6S, который в режиме Display Zoom переходил в разрешение iPhone 5. В iOS 11 и iPhone Xs нет Display Zoom, а в Xr и Xs Max он работает одинаково.

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

Автоматическое создание скриншотов

Сначала необходимо подготовить тесты. Проблема в том, что универсального решения не существует. То есть для автоматического создания скриншота вам нужен UI-тест. Однако традиционные UI-тесты, которые завязаны на элементы интерфейса, при смене локалей будут падать. Чтобы этого не происходило, нужно добавить элементам интерфейса accessebility Identifier’ы:

signinButton.accessebilityIdentifier = "btn_auth"

Сделать это можно как в коде, так и в Identity Inspector в Xcode.

Для демонстрации инструментов, о которых пойдет речь дальше, я подготовил простой тест. Он написан на Swift с помощью XCTest.

func testTutorial() {
        tutorialButton.tap()
        waitForElementToDissappear(element: tutorialButton, timeout: 5)
        makeScreenshot()
        for _ in 1...4 {
            app.swipeLeft()
            makeScreenshot()
        }
        tutorialCloseButton.tap()
        waitForElementToDissappear(element: tutorialCloseButton, timeout: 3)
    }

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

Вот как это выглядит на симуляторе:

Это скопированный со Stackoverflow метод создания скриншотов:

func makeScreenshot() {
        XCTContext.runActivity(named: "Making a full screenshot and saving it") { (activity) in
            let screen = XCUIScreen.main
            let fullscreenshot = screen.screenshot()
            let fullScreenshotAttachment = XCTAttachment(screenshot: fullscreenshot)
            fullScreenshotAttachment.lifetime = .keepAlways
            activity.add(fullScreenshotAttachment)
        }
    }

Это метод ожидания исчезновения элемента:

func waitForElementToDissappear(element: XCUIElement, timeout: Double) {
        let doesNotExistPredicate = NSPredicate(format: "exists == FALSE")
        expectation(for: doesNotExistPredicate, evaluatedWith: element, handler: nil)
        waitForExpectations(timeout: timeout, handler: nil)
    }

Есть два способа автоматического создания скриншотов на основе теста.

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

Настроить его не сложно:

По итогу создадутся два файла SnapshotHelper.swift и Snapfile, мы к ним еще вернемся.

Потом нужно будет для Fastlane создать UI Test Target. Берем UI Test Bundle:

Указываем цель для тестирования:

Потом обязательно указываем Target membership и переносим туда созданные файлы.

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

а Test вот так:

Теперь нам нужно инициализировать Fastlane с помощью функции setUp(), которая исполняется перед каждым запуском вашего тест-класса:

override func setUp() {
        continueAfterFailure = false
        setupnapshot(app)
        app.launch()
    }

И нужно будет немного поменять тест, который мы недавно написали, чтобы инициализировать вызов метода создания скриншотов в Fastlane. А именно заменить функцию makeScreenshot() на snapshot(«snapshot_name»), то есть Fastlane позволяет заранее настраивать названия скриншотов.

Плюс надо немного переписать цикл, чтобы у каждого скриншота было уникальное имя. Вот что у нас получилось:

func testTutorial() {
        tutorialButton.tap()
        waitForElementToDissappear(element: tutorialButton, timeout: 5)
        snapshot("Tutorial_page_1")
        var i: Int = 2
        repeat {
            app.swipeLeft()
            snapshot("Tutorial_page_\(i)")
            i += 1
        } while i <= 5
        tutorialCloseButton.tap()
        waitForElementToDissappear(element: tutorialCloseButton, timeout: 3)
    }

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

В list of device мы перечисляем устройства, для которых будем делать скриншоты; также указываем языки и схему, которая содержит UI-тесты, которые мы создали. Затем указываем место, куда будут сохраняться скриншоты, и задаём порядок действий с предыдущими скриншотами — нужно ли их удалять.

После запуска командой fastlane snapshot мы получаем HTML-страницу со скриншотами, которые можно группировать как по языку, так и по типу экрана.

Однако недостатком Fastlane является низкая скорость работы. Даже для нашего маленького проекта из 5 страниц программа генерировала скриншоты под 4 разрешения и на 5 языках целых 28 минут. А на реальном проекте уходили часы. Поэтому мы отказались от Fastlane.

Ещё один инструмент для автоматического создания скриншотов — XCTest Plan. Его представили на WWDC 2019 вместе с Xcode 11. Новая функциональность позволяет тестировщикам и разработчикам конфигурировать тесты согласно своим потребностям: определять, какие тесты запускать в сборке и в каком порядке, что делать с артефактами. И самое главное, XCTest Plan позволяет нам относительно безболезненно и быстро создавать скриншоты прямо внутри Xcode без внешних зависимостей.

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

После конвертации получим конфигурационный файл:

И теперь нужно сделать по копии для каждого из выбранных языков. Эти копии будут отличаться лишь строкой application language:

В Shared settings мы оставляем system language, это, в нашем случае, английский язык:

Теперь остается только запустить тест. Это можно сделать двумя способами:

правой кнопкой —> Run yourTestName():

причем можно запустить тест как во всех конфигурациях сразу, так и отдельно для каждого языка

и командой Xcodebuild:

Xcodebuild 
    -workspace ExnessForHeisenbug.xcworkspace/
    -scheme ExnessForHeisenbug
    -destination 'platform=iOS Simulator,OS=10.3.1,name=iPhone 6s'
    -destination 'platform=iOS Simulator,OS=11.4,name=iPhone 7 plus' 
    -destination 'platform=iOS Simulator,OS=12.2,name=iPhone Xs' 
    -destination 'platform=iOS Simulator,OS=12.2,name=iPhone SE' 
    test -testPlan ExnessForHeisenbug

Здесь мы указываем рабочее пространство, схему, testPlan и destination. Можно не только выбрать разные модели телефонов, но и задать им разные версии iOS, таким образом решив проблему фрагментации операционных систем.

Давайте запустим наш XCTest Plan. Он для четырёх симуляторов поочерёдно меняет локали и делает скриншот каждой страницы, а в конце удаляет симуляторы. Работает намного быстрее Fastlane.

На выходе мы получаем отчёт testTutorial:

Здесь проявляется один из недостатков XCTest Plan: смотреть скриншоты довольно неудобно. В Fastlane создаётся HTML-страница, в которой можно группировать скриншоты, а здесь каждый раз приходится нажимать на предпросмотр. Насколько мне известно, Xcode позволяет экспортировать изображения, но по какой-то причине мне это сделать не удалось. Либо мой XCTest Plan не так настроен, либо это баг Xcode.

В целом же это очень крутой нативный инструмент. Я надеюсь, что Apple будет его в дальнейшем поддерживать, развивать, править возникающие баги. То, что Fastlane сделал за 28 минут, XCTest Plan сделал за 2,6 минуты. То есть в 10 раз быстрее.

Анализ скриншотов

Мы получили скриншоты, теперь нужно их сравнить. Это можно сделать автоматически, так называемое снэпшот-тестирование: при первом запуске теста создаётся некое эталонное изображение, с которым будут сравниваться скриншоты при всех последующих запусках.

Среди бесплатных инструментов для снэпшот-тестирования хочу отметить два фреймворка:

Первый — это iOS Snapshot Test Case, библиотека, написанная на Objective C. Она преобразует UIView/CALayer в изображения и сравнивает их. При первом запуске записываем (recordMode = true) референс (эталон). При последующих запусках (recordMode = false), сравниваем полученные скриншоты с эталоном.

Здесь на второй картинке сместились логотипы и фраза Deposit is in your account! Long title! Test it Elon Musk!, а также изменился цвет надписи 120 000 000.00 USD. То есть сразу видно, в чем проблема.

Этот фреймворк довольно гибко настраивается. Мы можем поставить заплатки вместо динамических элементов, из-за изменения которых тесты падают. Например, можно сделать заплатку вместо transaction id, который уникальный в каждом тесте.

Обратите внимание на отсутствие Статус бара (панели с часами). Мы её отрезали, потому что время меняется, и тест падает.

Для настройки фреймворка нужно указать pod

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

FB_REFERENCE_IMAGE_DIR — куда кладётся эталон, и

IMAGE_DIF_DIR — куда будут складываться дифы при сбое теста.

Одним из достоинств фреймворка является визуализация различий между скриншотами. Также он по-человечески именует скриншоты, красиво раскладывает их по папкам. Почему это важно, вы поймете, когда я расскажу о следующем фреймворке.

Второй фреймворк — это Swift Snapshot Testing, он создан в Point Free Co. Работает по тому же принципу: записывает эталон и сравнивает с ним. Фреймворк принимает и JSON, и дампы, и URL, практически что угодно.

Настраивается он тоже довольно просто. Eсли импортировать модуль Import Snapshot Testing, то в функции assertSnapshot() мы будем сравнивать ViewController как изображение. При первом запуске фреймворк создаст эталон и будет сообщает о несовпадениях с ним при всех последующих запусках.

import SnapshotTesting
import XCTest

class MyViewControllerTests: XCTestCase {
  func testMyViewController() {
    let vc = MyViewController()

    assertSnapshot(matching: vc, as: .image)
  }
}

К достоинствам инструмента можно отнести то, что он написан на Swift и всеяден. Главный недостаток — отсутствие diff: фреймворк лишь сообщает о самом факте несовпадения. плюс бардак с наименованием и размещением скриншотов. Допилить его можно, благо, что он open source, но из коробки работает не так, как бы нам хотелось.

Резюме

Мы поговорили о двух инструментах, которые упрощают выгрузку и проверку локализованных текстов для приложений. Затем рассмотрели два фреймворка — новый XCTest Plan и старый Fastlane. С их помощью можно автоматически создавать скриншоты интерфейса. И в заключение рассмотрели два инструмента для снэпшот-тестирования.

У нас в Exness сейчас два мобильных проекта: Exness Trading, личный кабинет трейдера, и Social Trading, позволяющий просто положить деньги и копировать сделки других более опытных трейдеров.

Crowdin у нас до сих пор используется в обоих проектах. От LinguanApp в Exness Trading мы отказались, потому что у нас довольно много плейсхолдеров, которые актуальны только для одной локали, а автоматическая валидация постоянно давала сбои. Зато этот инструмент продолжает использовать команда Social Trading. Также в этом проекте используется Fastlane для создания и загрузки билдов. С XCTest Plan мы экспериментируем в обоих приложениях. Наконец, в Exness Trading мы внедряем Swift Snapshot Test Case, а в Social Trading — iOS Snapshot Test Case. Спасибо что дочитали до конца, надеюсь эта статья будет вам полезной. Happy testing!

Что еще можно почитать/посмотреть по теме:

Fastlane:

https://agostini.tech/2018/07/15/automatic-screenshots-with-fastlane-snapshot/
https://docs.fastlane.tools/getting-started/ios/screenshots/

XCTestPlan:

https://shashikantjagtap.net/wwdc19-getting-started-with-test-plan-for-xctest/
https://developer.apple.com/videos/play/wwdc2019/403
https://developer.apple.com/videos/play/wwdc2019/413

swift-snapshot-testing:

https://github.com/pointfreeco/swift-snapshot-testing/

ios-snapshot-test-case:

https://github.com/uber/ios-snapshot-test-case/

Display Zoom:

http://www.iphonehacks.com/2014/09/use-display-zoom-iphone-6-plus.html

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

Почему в телефоне нет музыки по умолчанию? Если вы купили Айфон, то вы наверняка хотите воспользоваться всеми функциями вашего устройства. Но по умолчанию производитель не дает вам обширную аудиоколлекцию в вашем телефоне — на устройстве практически нет музыки. Причина в … Читать далее →

Наш проект создан для помощи людям. Он носит рекомендательный характер и позволяет людям посчитать различные банковские продукты. Все статьи на сайте имеют лишь информационный характер и призваны помочь людям в поиске и выборе оптимального банковского продукта. Материалы являются авторскими и … Читать далее →

Сейчас для многих компаний важен и актуален стал такой канал продаж, как продажи через интернет. Но продавать можно не только в браузере, но и через телефон клиента. Для этого нужно создать мобильный клиент для каждого телефона — т.е. несколько мобильных … Читать далее →

В последнее время на музыкальной арене разворачивается нешуточная война за клиентов Apple. Fidel и Tracksflow закрыты, Я.М берет деньги за свое мобильное приложение, все большее количество пользователей предпочитают слушать музыку через ВК и создают плей-листы именно в социалках. Но все … Читать далее →

При выпуске любого мобильного приложения — для Android или для iPhone — важны три составляющие: дизайн, разработка и продвижение. Причем продвижение это где то 50% затрат, разработка и дизайн соответственно по 25%. Именно в таких пропорциях я советую закладываться при … Читать далее →

В начале текущего года я решил создать собственное мобильное приложение. Найти дизайнера, программистов и выпустить в AppStore свой программный продукт. Сейчас кредитный калькулятор в AppStore на рассмотрении. И я хочу рассказать, как я делал локализацию своего мобильного приложения. Итак, код … Читать далее →

Любая разработка после согласования технических требований начинается с ТЗ. В том числе и разработка мобильного приложения. Я попытался создать ТЗ для своего приложения для iPad — кредитный калькулятор. До этого я не часто встречался с различного рода ТЗ для iOS … Читать далее →

Недавно я прочитал о возможности вернуть платное приложение в Appstore после покупки и получить свои деньги обратно. Никогда не подумал бы, что это мне пригодится. Однако вышло иначе. Не так давно я захотел сделать свое приложение — кредитный калькулятор. Я … Читать далее →

Привет!!! Сегодня я хочу рассказать какие трудности и типичные ошибки возникают при тестировании мобильных приложений, которые локализованы на нескольких языках. Как я писал в одном из своих постов, качество приложения в AppStore определяется не только объемами продаж, но и отзывами … Читать далее →

На данный момент наиболее распространенными типами подключения к интернет для телефонов на Android и iOS является Wifi и 3G(Edge). Именно на этих подключениях обычно тестируют мобильные приложения, которые взаимодействуют с сетью. Подключение через Wifi Данный тип подключения является достаточно быстрым. … Читать далее →

Практическое руководство для начинающих

Сборник базовых знаний для тестирования приложений iOS:

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

Это было про iPhone Стива Джобса. Стив действительно заставил Apple работать над тем, чтобы их мобильное устройство стало самым любимым устройством для всех.

Пользователи всегда любили мобильные устройства Apple, будь то iPhone, iPod Touch или iPad.Текущие данные показывают, что в мире работает почти 1 миллиард устройств Apple, работающих под управлением iOS.

Это целый миллиард из них.

Ниже приводится анализ доли рынка iPhone в 2016 году:

[источник изображения]

iOS

iOS — мобильная операционная система, которая была разработана Apple специально для их устройств. часто называют iDevices.С 2007 года, когда iOS была выпущена только для iPhone, операционная система эволюционировала для поддержки сенсорных устройств и iPad.

Текущие исследования показывают, что iOS — вторая по популярности мобильная операционная система на рынке. Android работает на устройствах, созданных различными производителями, но прелесть iOS в том, что она ограничена только оборудованием Apple, что ясно указывает на популярность операционной системы.

iOS было выпущено в общей сложности 10 основных выпусков за годы и предлагало заметные обновления функций в каждом выпуске.

Эта операционная система iOS известна своим удобством в использовании, плавностью операций, приложениями без сбоев и т. Д. Если говорить о приложениях, то магазин приложений Apple iTunes для iOS слишком богат: количество приложений достигает 2,2 миллион. Количество скачиваний приложений стремительно выросло до 130 миллиардов.

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

Не только языки, но даже пользовательский интерфейс устройств iOS очень привлекателен и стильный по сравнению с устройствами Android.

Говоря о приложениях подробно, ниже приведены некоторые статистические данные по ним:

Магазин приложений Apple iTunes получает почти 1000 новых приложений каждый день.
Около 1/3 ^из всех приложений в магазине приложений Apple iTunes можно загрузить бесплатно.
Плата за приложение для iOS составляет в среднем от 1,10 до 1,30 доллара.
Средняя цена игры для iOS колеблется от 0,55 до 0,65 $.

Сколько приложений вы использовали на своем iPhone, iPod Touch или iPad?

Довольно много! Правильно? Начиная с Gmail и Facebook и заканчивая Clash of Clans и Asphalts. Такие приложения, количество и разнообразие пользователей приносят серьезный бизнес тестировщикам программного обеспечения. Не так ли ??

Как тестировщик, необходимо провести не только функциональность, но и всестороннее тестирование пользовательского интерфейса, чтобы проверить приложение на iPhone, iPod и iPad из-за различий в размерах.

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

Как обсуждалось ранее, iOS ограничена только оборудованием Apple или устройствами Apple. Это действительно огромное облегчение. Однако существует множество устройств Apple и их версий, поддерживающих iOS.

Суть в том, что у Apple закрытая система, в отличие от Android, которая является открытой системой. Релизы ОС или устройств хорошо спланированы.

Это дополнительное преимущество, потому что:

Размер устройств, которые доступны или будут выпущены, является фиксированным, и как QA мы должны иметь очень четкое представление о том, какие устройства отсутствуют на рынке .Для QA становится легко выбрать испытательный стенд для тестирования
Как и для устройств, нам не нужно проводить глубокий анализ ОС, поскольку это закрытая система, принятие решения требует меньше времени (и усилий). про стенд для тестирования ОС.
У Apple есть множество собственных инструментов автоматизации, хотя их немного сложно изучить.
Я помню, что для тестирования GPS на Android мне пришлось потратить 2-3 дня на то, чтобы узнать, как создавать фиктивные скрипты для отправки поддельного местоположения.Но в iOS это было очень просто и понятно, поскольку в него встроена функция отправки поддельного GPS при ходьбе, беге, езде на велосипеде и т. Д.
Для первоначального тестирования не рекомендуется проверять GPS полевым тестом, отправляя фиктивный GPS. данные рекомендуется, и это также экономит время.
У Apple есть строгие правила подачи заявки, это в некотором смысле большое подспорье, а не отказ после подачи, и хорошие шансы на успех, в отличие от других ОС, где нет строгих правил.
Функциональные возможности устройства и самой ОС фиксированы и просты, следовательно, это снижает вероятность упустить способы работы приложения. В iOS нет способа принудительно остановить приложение, в то время как мы можем убить и принудительно остановить приложения на Android. Таким образом снижаются сложности для тестирования здесь.

Это некоторые из преимуществ, которые мы получаем от продуктов Apple, но не обязательно, что это преимущества каждого продукта или приложения. В то время как с приложениями, разработанными на кроссплатформенности, трудно справиться с iOS.

Классификация высокого уровня показана ниже:

Первым шагом на пути к тестированию приложений iOS является рассмотрение типа реализации.

Реализация приложения может быть любого из трех следующих типов:

1) Веб-приложения: Это приложения, которые ведут себя аналогично построению в приложениях iOS. Это обычные веб-сайты, к которым пользователь заходит в браузере iPhone Safari.

2) Собственное приложение: Приложение, которое разработано с использованием iOS SDK [Software Development Kit], изначально работает на поддерживаемых устройствах iOS, таких как VLC, Flipboard, Uber и т. Д.

3) Гибридное приложение: Это смесь или гибрид обоих типов, упомянутых выше. Это дает доступ к веб-контенту через область просмотра веб-контента, а также имеет некоторые элементы пользовательского интерфейса для iOS. Напр. Zomato, Twitter, Gmail и т. Д.

Типы тестирования приложений iOS

Различные типы тестирования приложений iOS [как это делается в типичных условиях] могут быть следующими:

Ручное тестирование — с использованием устройства
- Система Тестирование
- UI / UX-тестирование
- Тестирование безопасности
- Полевое тестирование
Ручное тестирование — с помощью эмулятора
- Модульное тестирование
- Интеграционное тестирование
- UI-тестирование
Автоматическое тестирование
- Регрессионное тестирование
- BVT-тестирование
- Тестирование совместимости
- Тестирование производительности

Пример приложения:

Прежде чем переходить к различным аспектам процессов тестирования iOS, давайте рассмотрим пример типичного приложения iOS.

Рассмотрим заявку на сбор средств спортивной команды. Приложение будет иметь учетную запись социальной сети [Google / Facebook] и страницу оплаты.

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

Ручное тестирование — Использование устройства

a) Тестирование системы:

Этот тип тестирования iOS выполняется в системе, чтобы проверить, работают ли различные компоненты системы вместе.

В этом процессе тестирования приложение iOS запускается на реальном устройстве Apple с последующим его взаимодействием с пользовательским интерфейсом для запуска определенного набора или наборов действий пользователя. Типичными действиями пользователя могут быть сенсорные операции или операции смахивания по экрану.

Наконец, результат сравнивается с ожидаемым.

Для нашего примера, приведенного выше, типичный системный тест может состоять из следующих шагов:

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

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

b) Тестирование пользовательского интерфейса iOS

Пользовательский интерфейс / пользовательский интерфейс устройств iOS был ключевым элементом в их истории успеха.

Тестирование UI / UX на устройствах iOS можно разделить на следующие категории:

Входы: Тестирование функций сенсорного экрана [таких как длинное / короткое касание, 3D касание, прокрутка], размеры кнопок, расположение кнопки, цвет шрифтов и их размер и т. д., попадают в эту категорию.
Аппаратные клавиши: Родные приложения без проблем работают со встроенными аппаратными клавишами / аппаратными клавишами, присутствующими на устройстве, такими как кнопка «Домой», кнопки звука и т. Д. Тестируемое приложение также должно взаимодействовать с аппаратными клавишами аналогичным образом.
Программные клавиши / Программная клавиатура: Насколько это раздражает, когда клавиатура не отображается, когда вы находитесь на странице сообщений Whatsapp? Внешний вид клавиатуры, возможность скрытия, когда она вам не нужна, поддержка смайлов, символов, всех символов / символов и т. Д.необходимы.
В нашем примере клавиатура может появляться в изображении в нескольких местах, таких как ввод пользовательской суммы, ввод учетных данных / данных карты в платежном шлюзе и т. Д.
Экран: Приложение, если оно поддерживается несколькими устройства должны быть проверены на его ориентацию во всех устройствах. Разрешение может измениться в зависимости от устройства, выбранного для процесса тестирования. В то же время следует провести тестирование портретного / ландшафтного режимов и использования клавиатуры в каждом из случаев.

Если ваше приложение создано не только для iOS, то есть несколько указателей, которые необходимо специально протестировать для iOS, например:

Списки: В iOS, когда есть список для отображения, он всегда отображается совершенно новый экран, в отличие от Android, на котором появляется всплывающее окно.

Ниже приводится пример того же:

[источник]

Сообщения: Когда приложение вылетает, сообщение, отображаемое в iOS, отличается от сообщения в Android.Кроме того, если вы заметили, на телефонах Android появляются небольшие сообщения, когда вы освобождаете память, например, «# ГБ памяти освобождено» и т. Д., Но мы никогда не увидим flash-сообщения в iOS.

Ниже приведен пример:

[источник]

Подтверждение удаления: Если вы внимательно посмотрите на приложение iOS, во всплывающем окне с подтверждением удаления действие Отмена находится слева от параметр Удалить. В Android или другой ОС все наоборот.

Это некоторые из примеров, которые требуют отдельных тестовых случаев и тестирования, поскольку iOS имеет пользовательский интерфейс по умолчанию, сообщения и т. Д., Которые нельзя изменить.

c) Тестирование безопасности:

В нашем примере у нас есть приложение с платежным шлюзом и страницей входа, поддерживаемые интеграцией социальных страниц.

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

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

г) Полевые испытания:

Полевые испытания проводятся для проверки поведения приложения в сети передачи данных телефона.

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

Ручное тестирование — с помощью эмулятора

a) Модульное тестирование:

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

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

б) Интеграционное тестирование:

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

В наших примерах мы можем назвать логин одним модулем, а платежный шлюз — другим модулем.

Модульное тестирование охватывает тестирование обоих по отдельности. Однако интеграционное тестирование проверит целостность обоих модулей.

c) Тестирование пользовательского интерфейса:

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

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

iOS Automation

a) Регрессионное тестирование:

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

Проще говоря, внесенные изменения могут привести к появлению нового набора проблем в приложении.

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

b) BVT Testing:

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

c) Тестирование совместимости:

Как уже говорилось, Apple выпускает множество устройств / типов.Если быть точным, на рынке представлено 15 различных типов iPhone, 6 моделей iPod Touch, 10 моделей iPad и 2 модели iPad Pro.

Теперь, когда разработано такое приложение, как наше [Приложение по сбору средств для спортивных команд], оно должно поддерживаться всеми вышеупомянутыми устройствами. Это подразумевает одно: все тестовые примеры должны выполняться на всех этих устройствах.

Теперь ручное усилие невозможно, когда количество устройств очень велико. Для совместимости предпочтительно автоматическое тестирование.

d) Тестирование производительности:

В ходе тестирования производительности были протестированы следующие:

Как ведет себя приложение, когда оно работает или работает в течение очень долгого времени. Во время рабочего периода заставьте приложение общаться / взаимодействовать / оставаться в режиме ожидания.
Одна и та же операция должна выполняться каждый раз с разным количеством нагрузок.
Как ведет себя система, когда объем передаваемых данных действительно огромен.

Эти дела носят повторяющийся характер и в основном выполняются с использованием автоматизации.

iOS Automation Frameworks

Некоторые из наиболее часто используемых платформ автоматизации перечислены ниже:

# 1) Appium:

Appium использует драйвер Selenium Web для автоматизации тестирования приложений iOS.

Эта платформа является независимой и может использоваться как в Интернете, так и на мобильных устройствах [как Android, так и iOS]. Это программа с открытым исходным кодом и не ограничена языком. Изменения приложений или доступ к исходному коду не требуются для автоматизации с помощью Appium.

Appium работает без проблем независимо от типа приложения: будь то собственное, гибридное или веб-приложение.

# 2) Calabash:

Calabash — это кроссплатформенная среда с открытым исходным кодом, которая поддерживает автоматическое тестирование Android и iOS.

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

# 3) Эрл Грей:

Эрл Грей — это собственная внутренняя среда тестирования пользовательского интерфейса Google. Это было использовано для тестирования YouTube, Google Фото, Google Play Music, Google Calendar и т. Д.

Earl Gray недавно был открыт с открытым исходным кодом.Некоторые из основных преимуществ Earl Gray: встроенная синхронизация, проверка видимости перед взаимодействием, истинное взаимодействие с пользователем [нажатие, пролистывание и т. Д.]. Это очень похоже на Espresso от Google, который используется для автоматизации пользовательского интерфейса Android.

# 4) Автоматизация пользовательского интерфейса:

Автоматизация пользовательского интерфейса разработана Apple и очень похожа на UI Automator для Android. API определены Apple, а тесты написаны на JAVA.

# 5) KIF:

KIF означает «Сохраняйте функциональность».Это сторонняя платформа с открытым исходным кодом.

Это среда тестирования интеграции iOS, которая тесно связана с тестовыми целями XCTest и используется для них. KIF легко настроить или интегрировать с проектом Xcode, поэтому дополнительный веб-сервер или дополнительные пакеты не требуются. KIF имеет широкий охват с точки зрения версий iOS.

Заключение

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

Однако выбор правильного подхода, оптимального процесса тестирования, методологий, инструментов, эмуляторов / устройств и т. Д. Сделает тестирование приложений iOS очень успешным.

В нашем предстоящем руководстве вы узнаете все основные концепции, используемые в руководстве по тестированию приложений Android.

.Учебное пособие по тестированию приложений iOS

: руководство и автоматизация

Home
Testing
- - Back
  - Agile Testing
  - BugZilla
  - Cucumber
  - Database Testing
  - J2000
  - J2000 Тестирование базы данных
  - Назад
  - JUnit
  - LoadRunner
  - Ручное тестирование
  - Мобильное тестирование
  - Mantis
  - Почтальон
  - QTP
  - Назад
  - Центр качества (ALM)
  - Центр качества (ALM)
  - Управление тестированием
  - TestLink
SAP
- - Назад
  - ABA P
  - APO
  - Начинающий
  - Basis
  - BODS
  - BI
  - BPC
  - CO
  - Назад
  - CRM
  - Crystal Reports
  - QM4O
  - Заработная плата
  - Назад
  - PI / PO
  - PP
  - SD
  - SAPUI5
  - Безопасность
  - Менеджер решений
  - Successfactors
  - SAP Tutorials
  4
- Web
- Apache
- AngularJS
- ASP.Net
- C
- C #
- C ++
- CodeIgniter
- СУБД
- JavaScript
- Назад
- Java
- JSP
- Kotlin
- Linux
- Linux
- Kotlin
- Linux
- Perl
- Назад
- PHP
- PL / SQL
- PostgreSQL
- Python
- ReactJS
- Ruby & Rails
- Scala
- SQL
- SQL
- UML
- VB.Net
- VBScript
- Веб-службы
- WPF

Обязательно учите!

- Назад
- Бухгалтерский учет
- Алгоритмы
- Android
- Блокчейн
- Business Analyst
- Создание веб-сайта
- CCNA
- Облачные вычисления
- 00030003 COBOL 9000 Compiler
  - 00030002 9000 Compiler 9000
  - Ethical Hacking
  - Учебники по Excel
  - Программирование на Go
  - IoT
  - ITIL
  - Jenkins
  - MIS
  - Сеть
  - Операционная система
  - Назад
  - Управление проектами Обзоры
  - Salesforce
  - SEO
  - Разработка программного обеспечения
  - VB A
Big Data
- - Назад
  - AWS
  - BigData
  - Cassandra
  - Cognos
  - Хранилище данных
  - HBOps
  - HBOps
  - MicroStrategy

Учебное пособие по модульному тестированию iOS и пользовательскому интерфейсу

Примечания к обновлению : Майкл Кац обновил это руководство для Xcode 10.1, Swift 4.2 и iOS 12. Одри Тэм написала оригинал.

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

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

~~Из этого туториала Вы узнаете:~~

~~Как использовать тестовый навигатор Xcode для тестирования модели приложения и асинхронных методов~~
~~Как имитировать взаимодействия с библиотекой или системными объектами с помощью заглушек и имитаторов~~
~~Как проверить пользовательский интерфейс и производительность~~
~~Как использовать инструмент покрытия кода~~

~~Попутно вы освоите словарный запас, используемый при тестировании ниндзя.~~

Выяснение, что тестировать

~~Прежде чем писать какие-либо тесты, важно знать основы. Что нужно протестировать?~~

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

~~Как правило, тесты должны охватывать:~~

~~Основные функции: классы и методы модели и их взаимодействие с контроллером~~
~~Наиболее распространенные рабочие процессы пользовательского интерфейса~~
~~Граничные условия~~
~~Исправления ошибок~~

Лучшие практики тестирования

~~Аббревиатура FIRST описывает краткий набор критериев для эффективных модульных тестов.Эти критерии:~~

Fast : Тесты должны выполняться быстро.
Независимый / изолированный : Тесты не должны разделять состояние друг с другом.
Повторяемый : Вы должны получать одни и те же результаты каждый раз при запуске теста. Внешние поставщики данных или проблемы с параллелизмом могут вызывать периодические сбои.
Самостоятельная проверка : Тесты должны быть полностью автоматизированы. Результат должен быть либо «прошел», либо «не прошел», а не полагаться на интерпретацию файла журнала программистом.
Своевременное : В идеале тесты следует писать до того, как вы напишете производственный код, который они тестируют (разработка через тестирование).

Следование принципам FIRST сделает ваши тесты понятными и полезными, вместо того, чтобы превращаться в препятствия для вашего приложения.

Начало работы

Начните с загрузки материалов проекта с помощью кнопки Загрузить материалы вверху или внизу этого руководства. Есть два отдельных стартовых проекта: BullsEye и HalfTunes.

BullsEye основан на примере приложения из iOS Apprentice . Логика игры находится в классе BullsEyeGame , который вы протестируете во время этого урока.
HalfTunes — это обновленная версия примера приложения из руководства по URLSession. Пользователи могут запрашивать песни в iTunes API, а затем загружать и воспроизводить фрагменты песен.

Модульное тестирование в Xcode

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

Создание цели модульного теста

~~Откройте проект BullsEye и нажмите Command-6 , чтобы открыть навигатор тестов.~~

~~Нажмите кнопку + в нижнем левом углу, затем выберите New Unit Test Target… из меню:~~

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

Шаблон по умолчанию импортирует среду тестирования, XCTest , и определяет подкласс BullsEyeTests из XCTestCase с setUp () , tearDown () и примеры методов тестирования.

~~Есть три способа запустить тесты:~~

Продукт ▸ Тест или Command-U . Оба они запускают всех тестовых классов .
~~Щелкните кнопку со стрелкой в навигаторе тестов.~~
~~Щелкните ромбовидную кнопку в желобе.~~

~~Вы также можете запустить отдельный метод тестирования, щелкнув его ромбик в навигаторе тестов или в желобе.~~

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

Когда все тесты пройдут успешно, ромбы станут зелеными и покажут галочки. Вы можете щелкнуть серый ромб в конце testPerformanceExample () , чтобы открыть Результат производительности:

~~Для этого руководства вам не нужны testPerformanceExample () или testExample () , поэтому удалите их.~~

Использование XCTAssert для тестирования моделей

Во-первых, вы воспользуетесь функциями XCTAssert , чтобы проверить основную функцию модели BullsEye: правильно ли объект BullsEyeGame подсчитывает счет за раунд?

~~В BullsEyeTests.swift добавьте эту строку сразу под оператором import :~~

@testable import BullsEye

~~Это дает модульным тестам доступ к внутренним типам и функциям в BullsEye.~~

~~В верхней части класса BullsEyeTests добавьте это свойство:~~

вар сут: BullsEyeGame!

Это создает заполнитель для BullsEyeGame , который является тестируемой системой (SUT) или объектом, с которым этот класс тестового примера связан с тестированием.

~~Затем замените содержимое setup () на это:~~

super.setUp ()
sut = BullsEyeGame ()
sut.startNewGame ()

Это создает объект BullsEyeGame на уровне класса, поэтому все тесты в этом тестовом классе могут получить доступ к свойствам и методам объекта SUT.

Здесь вы также вызываете игру startNewGame () , которая инициализирует targetValue . Во многих тестах используется значение targetValue , чтобы проверить правильность подсчета очков в игре.

~~Прежде чем вы забудете, выпустите вашего объекта SUT в tearDown () . Заменить его содержимое на:~~

сут = ноль
super.tearDown ()

Примечание : Хорошая практика — создать SUT в setUp () и выпустить его в tearDown () , чтобы гарантировать, что каждый тест начинается с чистого листа.Дополнительную информацию можно найти в публикации Джона Рида по этой теме.

Написание вашего первого теста

~~Теперь вы готовы написать свой первый тест!~~

~~Добавьте следующий код в конец BullsEyeTests :~~

func testScoreIsComputed () {
  // 1. данный
  пусть угадают = sut.targetValue + 5

  // 2. когда
  сут.проверка (угадать: угадать)

  // 3. тогда
  XCTAssertEqual (sut.scoreRound, 95, «Оценка, вычисленная на основе предположения, неверна»)
}

~~Название метода тестирования всегда начинается с test , за которым следует описание того, что он проверяет.~~

~~Хорошей практикой является форматирование теста в для , , когда и , затем разделов:~~

Учитывая : Здесь вы устанавливаете любые необходимые значения. В этом примере вы создаете значение guess , чтобы указать, насколько оно отличается от targetValue .
Когда : В этом разделе вы выполните тестируемый код: вызовите check (угадайте :) .
Затем : это раздел, в котором вы подтверждаете ожидаемый результат с сообщением, которое печатается, если тест не проходит .В этом случае sut.scoreRound должно равняться 95 (100 — 5).

Запустите тест, щелкнув значок ромба в желобе или в навигаторе тестов. Это создаст и запустит приложение, а значок ромба изменится на зеленую галочку!

Отладка теста

В BullsEyeGame специально встроена ошибка, и сейчас вы попрактикуетесь в ее обнаружении. Чтобы увидеть ошибку в действии, вы создадите тест, в котором вычитает 5 из targetValue в заданном разделе и оставляет все остальное без изменений.

~~Добавьте следующий тест:~~

func testScoreIsComputedWhenGuessLTTarget () {
  // 1. данный
  пусть угадывают = sut.targetValue - 5

  // 2. когда
  сут.проверка (угадать: угадать)

  // 3. тогда
  XCTAssertEqual (sut.scoreRound, 95, «Оценка, вычисленная на основе предположения, неверна»)
}

~~Разница между guess и targetValue по-прежнему равна 5, поэтому результат должен быть 95.~~

В навигаторе точек останова добавьте Test Failure Breakpoint .Это остановит тестовый прогон, когда тестовый метод отправит утверждение об ошибке.

~~Запустите тест, и он должен остановиться на строке XCTAssertEqual с ошибкой теста.~~

~~Проверить сут и угадать в консоли отладки:~~

~~предположить, что — это targetValue - 5 , но очков. раунд — это 105, а не 95!~~

Для дальнейшего исследования используйте обычный процесс отладки: установите точку останова на , когда оператор , а также один на BullsEyeGame.swift , внутри проверьте (угадайте :) , где он создает разницу . Затем запустите тест еще раз и перейдите к инструкции let difference , чтобы проверить значение разница в приложении:

Проблема в том, что разница в отрицательна, поэтому результат 100 — (-5) . Чтобы исправить это, вы должны использовать абсолютное значение из разницы . В проверьте (угадайте :) , раскомментируйте правильную строку и удалите неправильную.

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

Использование XCTestExpectation для тестирования асинхронных операций

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

Откройте проект HalfTunes . Он использует URLSession для запроса API iTunes и загрузки образцов песен. Предположим, вы хотите изменить его, чтобы использовать AlamoFire для сетевых операций.Чтобы увидеть, не сломается ли что-нибудь, вы должны написать тесты для сетевых операций и запускать их до и после изменения кода.

URLSession методы асинхронны : они возвращаются сразу же, но не завершают работу позже. Чтобы протестировать асинхронные методы, вы используете XCTestExpectation , чтобы ваш тест ждал завершения асинхронной операции.

~~Асинхронные тесты обычно медленные, поэтому вы должны держать их отдельно от более быстрых модульных тестов.~~

Создайте новую цель модульного теста с именем HalfTunesSlowTests . Откройте класс HalfTunesSlowTests и импортируйте модуль приложения HalfTunes чуть ниже существующего оператора import :

@testable import HalfTunes

Все тесты в этом классе используют URLSession по умолчанию для отправки запросов на серверы Apple, поэтому объявите объект sut , создайте его в setUp () и отпустите в tearDown () .

~~Заменить содержимое класса HalfTunesSlowTests на:~~

var sut: URLSession!

override func setUp () {
  super.setUp ()
  sut = URLSession (конфигурация: по умолчанию)
}

override func tearDown () {
  сут = ноль
  super.tearDown ()
}

~~Затем добавьте этот асинхронный тест:~~

// Асинхронный тест: быстрый успех, медленный отказ
func testValidCallToiTunesGetsHTTPStatusCode200 () {
  // данный
  пусть url =
    URL (строка: "https: // itunes.apple.com/search?media=music&entity=song&term=abba ")
  // 1
  let обещание = ожидание (описание: «Код состояния: 200»)

  // когда
  let dataTask = sut.dataTask (with: url!) {данные, ответ, ошибка в
    // тогда
    if let error = error {
      XCTFail ("Ошибка: \ (error.localizedDescription)")
      возвращение
    } иначе, если разрешить statusCode = (ответ как? HTTPURLResponse) ?. statusCode {
      if statusCode == 200 {
        // 2
        обещание.выполнить ()
      } else {
        XCTFail ("Код состояния: \ (statusCode)")
      }
    }
  }
  dataTask.resume ()
  // 3
  ждать (для: [обещание], тайм-аут: 5)
}

Этот тест проверяет, что отправка действительного запроса в iTunes возвращает код состояния 200. Большая часть кода совпадает с тем, что вы пишете в приложении, с этими дополнительными строками:

ожидание (описание 🙂 : возвращает объект XCTestExpectation , хранящийся в обещании .Описание Параметр описывает то, что вы ожидаете.
promise.fulfill () : вызовите это в закрытии условия успеха обработчика завершения асинхронного метода, чтобы отметить, что ожидание было выполнено.
wait (for: timeout 🙂 : Продолжает выполнение теста до тех пор, пока не будут выполнены все ожидания или пока не закончится интервал timeout , в зависимости от того, что произойдет раньше.

Запустить тест. Если вы подключены к Интернету, проверка должна занять около секунды после загрузки приложения в симуляторе.

Быстрый отказ

~~Неудача — это больно, но это не должно длиться вечно.~~

~~В случае сбоя просто удалите букву «s» из «itunes» в URL-адресе:~~

пусть url =
  URL (строка: "https://itune.apple.com/search?media=music&entity=song&term=abba")

Запустите тест. Это не удается, но требуется полный интервал тайм-аута! Это связано с тем, что вы предполагали, что запрос всегда будет успешным, и именно здесь вы вызвали Promise.fulfill () .Поскольку запрос не удался, он завершился только по истечении тайм-аута.

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

~~Чтобы увидеть, как это работает, создайте новый тест.~~

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

func testCallToiTunesCompletes () {
  // данный
  пусть url =
    URL (строка: "https://itune.apple.com/search?media=music&entity=song&term=abba")
  let обещание = ожидание (описание: «Вызван обработчик завершения»)
  var statusCode: Int?
  var responseError: Ошибка?

  // когда
  пусть dataTask = сут.dataTask (with: url!) {данные, ответ, ошибка в
    statusCode = (ответ как? HTTPURLResponse) ?. statusCode
    responseError = ошибка
    обещание.fulfill ()
  }
  dataTask.resume ()
  ждать (для: [обещание], тайм-аут: 5)

  // тогда
  XCTAssertNil (responseError)
  XCTAssertEqual (statusCode, 200)
}

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

Запустите тест. Теперь это должно занять около секунды. Он терпит неудачу, потому что запрос не удался, а не потому, что тестовый прогон превысил тайм-аут .

~~Исправьте URL-адрес , а затем снова запустите тест, чтобы убедиться, что он успешно завершен.~~

Подделка объектов и взаимодействий

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

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

Используйте подделку, если ваш код имеет зависимость от системного или библиотечного объекта. Вы можете сделать это, создав фальшивый объект для этой роли и внедрив фейка в свой код. Внедрение зависимостей от Джона Рида описывает несколько способов сделать это.

Поддельный ввод от заглушки

В этом тесте вы убедитесь, что приложение updateSearchResults (_ :) правильно анализирует данные, загруженные сеансом, проверив правильность searchResults.count . SUT — это контроллер представления, и вы можете имитировать сеанс с помощью заглушек и некоторых предварительно загруженных данных.

Перейдите в навигатор тестов и добавьте новую цель Unit Test .Назовите его HalfTunesFakeTests . Откройте HalfTunesFakeTests.swift и импортируйте модуль приложения HalfTunes сразу под оператором import :

@testable import HalfTunes

~~Теперь замените содержимое класса HalfTunesFakeTests на это:~~

var sut: SearchViewController!

override func setUp () {
  super.setUp ()
  sut = UIStoryboard (name: "Main", bundle: nil)
    .instantiateInitialViewController () как? SearchViewController
}

override func tearDown () {
  сут = ноль
  супер.срывать()
}

~~Это объявляет SUT, который является SearchViewController , создает его в setUp () и освобождает в tearDown () :~~

Примечание : SUT является контроллером представления, потому что у HalfTunes большая проблема контроллера представления — вся работа выполняется в SearchViewController.swift . Перемещение сетевого кода в отдельный модуль уменьшит эту проблему, а также упростит тестирование.

Затем вам понадобятся образцы данных JSON, которые ваш поддельный сеанс предоставит вашему тесту.Подойдет всего несколько элементов, поэтому для ограничения результатов загрузки в iTunes добавьте & limit = 3 к строке URL:

https://itunes.apple.com/search?media=music&entity=song&term=abba&limit=3

Скопируйте этот URL-адрес и вставьте его в браузер. Будет загружен файл с именем 1.txt , 1.txt.js или аналогичный. Просмотрите его, чтобы убедиться, что это файл JSON, затем переименуйте его в abbaData.json .

~~Теперь вернитесь к Xcode и перейдите в навигатор проекта.Добавьте файл в группу HalfTunesFakeTests .~~

Проект HalfTunes содержит вспомогательный файл DHURLSessionMock.swift . Это определяет простой протокол с именем DHURLSession с методами (заглушками) для создания задачи обработки данных с использованием либо URL , либо URLRequest . Он также определяет URLSessionMock , который соответствует этому протоколу с инициализаторами, которые позволяют создавать фиктивный объект URLSession с вашим выбором данных, ответа и ошибки.

Чтобы настроить подделку, перейдите к HalfTunesFakeTests.swift и добавьте следующее в setUp () после оператора, создающего SUT:

let testBundle = Bundle (для: type (of: self))
let path = testBundle.path (forResource: "abbaData", ofType: "json")
пусть данные = попробовать? Данные (contentsOf: URL (fileURLWithPath: path!), Параметры: .alwaysMapped)

пусть url =
  URL (строка: "https://itunes.apple.com/search?media=music&entity=song&term=abba")
пусть urlResponse = HTTPURLResponse (
  url: url !,
  statusCode: 200,
  httpVersion: nil,
  headerFields: ноль)

let sessionMock = URLSessionMock (данные: данные, ответ: urlResponse, ошибка: ноль)
сут.defaultSession = sessionMock

Это устанавливает поддельные данные и ответ и создает поддельный объект сеанса. Наконец, в конце он вводит поддельный сеанс в приложение как свойство sut .

Теперь вы готовы написать тест, который проверяет, анализирует ли вызов updateSearchResults (_ :) поддельные данные. Добавьте следующий тест:

func test_UpdateSearchResults_ParsesData () {
  // данный
  let обещание = ожидание (описание: «Код состояния: 200»)

  // когда
  XCTAssertEqual (
    сут.searchResults.count,
    0,
    "searchResults должен быть пустым перед запуском задачи данных")
  пусть url =
    URL (строка: "https://itunes.apple.com/search?media=music&entity=song&term=abba")
  let dataTask = sut.defaultSession.dataTask (with: url!) {
    данные, ответ, ошибка в
    // если HTTP-запрос прошел успешно, вызываем updateSearchResults (_ :)
    // который анализирует данные ответа на треки
    if let error = error {
      печать (error.localizedDescription)
    } иначе, если httpResponse = response as? HTTPURLResponse,
      httpResponse.statusCode == 200 {
      self.sut.updateSearchResults (данные)
    }
    обещание.fulfill ()
  }
  dataTask.resume ()
  ждать (для: [обещание], тайм-аут: 5)

  // тогда
  XCTAssertEqual (sut.searchResults.count, 3, «Не удалось проанализировать 3 элемента из поддельного ответа»)
}

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

при утверждении состоит в том, что searchResults пусто перед запуском задачи данных.Это должно быть правдой, потому что вы создали полностью новую SUT в setUp () .

Поддельные данные содержат JSON для трех объектов Track , поэтому утверждение затем состоит в том, что массив searchResults контроллера представления содержит три элемента.

~~Запустите тест. Это должно произойти довольно быстро, потому что нет реального сетевого подключения!~~

Поддельное обновление для Mock Object

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

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

~~Следующий тест проверит, правильно ли приложение сохраняет свойство gameStyle .~~

В навигаторе тестов щелкните New Unit Test Class и назовите его BullsEyeMockTests . Добавьте следующее под оператором import :

@testable import BullsEye

class MockUserDefaults: UserDefaults {
  var gameStyleChanged = 0
  переопределить набор функций (_ значение: Int, forKey defaultName: String) {
    if defaultName == "gameStyle" {
      gameStyleChanged + = 1
    }
  }
}

MockUserDefaults переопределяет набор (_: forKey :) для увеличения флага gameStyleChanged .Часто можно встретить аналогичные тесты, которые устанавливают переменную Bool , но приращение Int дает вам большую гибкость — например, ваш тест может проверить, что метод вызывается только один раз.

~~Объявите SUT и фиктивный объект в BullsEyeMockTests :~~

var sut: ViewController!
var mockUserDefaults: MockUserDefaults!

~~Затем замените стандартные setUp () и tearDown () на это:~~

override func setUp () {
  супер.настроить()

  sut = UIStoryboard (name: "Main", bundle: nil)
    .instantiateInitialViewController () как? ViewController
  mockUserDefaults = MockUserDefaults (имя набора: "тестирование")
  sut.defaults = mockUserDefaults
}

override func tearDown () {
  сут = ноль
  mockUserDefaults = nil
  super.tearDown ()
}

~~Это создает тестируемую систему и фиктивный объект, а также вводит фиктивный объект как свойство ТРИ.~~

~~Теперь замените в шаблоне два метода тестирования по умолчанию на это:~~

func testGameStyleCanBeChanged () {
  // данный
  пусть segmentedControl = UISegmentedControl ()

  // когда
  XCTAssertEqual (
    mockUserDefaults.gameStyleChanged,
    0,
    "gameStyleChanged должно быть 0 перед sendActions")
  segmentedControl.addTarget (сут,
    действие: #selector (ViewController.chooseGameStyle (_ :)), для: .valueChanged)
  segmentedControl.sendActions (для: .valueChanged)

  // тогда
  XCTAssertEqual (
    mockUserDefaults.gameStyleChanged,
    1,
    «Пользовательский стиль gameStyle по умолчанию не был изменен»)
}

Утверждение при состоит в том, что флаг gameStyleChanged равен 0 до того, как метод тестирования изменит сегментированный элемент управления.Итак, если утверждение , то также верно, это означает, что набор (_: forKey :) был вызван ровно один раз.

~~Запустить тест; это должно получиться.~~

Тестирование пользовательского интерфейса в Xcode

UI testing позволяет тестировать взаимодействие с пользовательским интерфейсом. Тестирование пользовательского интерфейса работает путем поиска объектов пользовательского интерфейса приложения с помощью запросов, синтеза событий и последующей отправки событий этим объектам. API позволяет вам исследовать свойства и состояние объекта пользовательского интерфейса, чтобы сравнить их с ожидаемым состоянием.

В навигаторе тестов проекта BullsEye добавьте новую UI Test Target . Убедитесь, что целью для тестирования является BullsEye , а затем примите имя по умолчанию BullsEyeUITests .

~~Откройте BullsEyeUITests.swift и добавьте это свойство в начало класса BullsEyeUITests :~~

var app: XCUIApplication!

~~В setUp () замените оператор XCUIApplication ().launch () со следующим:~~

app = XCUIApplication ()
app.launch ()

~~Измените имя testExample () на testGameStyleSwitch () .~~

~~Откройте новую строку в testGameStyleSwitch () и нажмите красную кнопку Record в нижней части окна редактора:~~

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

~~Теперь у вас есть следующие три строки в testGameStyleSwitch () :~~

let app = XCUIApplication ()
app.buttons ["Slide"]. tap ()
app.staticTexts ["Подойдите как можно ближе к:"] .tap ()

Регистратор создал код для проверки тех же действий, которые вы тестировали в приложении. Пошлите тап по слайдеру и метке. Вы будете использовать их как основу для создания собственного теста пользовательского интерфейса.
Если вы видите другие утверждения, просто удалите их.

Первая строка дублирует свойство, которое вы создали в setUp () , поэтому удалите эту строку. Пока вам не нужно ничего нажимать, поэтому также удалите .tap () в конце строк 2 и 3. Теперь откройте небольшое меню рядом с ["Slide"] и выберите segmentedControls.buttons [ «Слайд»] .

~~У вас должно быть следующее:~~

app.segmentedControls.buttons ["Слайд"]
app.staticTexts ["Подойдите как можно ближе к:"]

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

// данный
let slideButton = app.segmentedControls.buttons ["Слайд"]
let typeButton = app.segmentedControls.buttons ["Тип"]
let slideLabel = app.staticTexts ["Подойдите как можно ближе к:"]
let typeLabel = app.staticTexts ["Угадайте, где находится ползунок:"]

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

// тогда
если slideButton.isSelected {
  XCTAssertTrue (slideLabel.exists)
  XCTAssertFalse (typeLabel.exists)

  typeButton.tap ()
  XCTAssertTrue (typeLabel.exists)
  XCTAssertFalse (slideLabel.exists)
} else if typeButton.isSelected {
  XCTAssertTrue (typeLabel.exists)
  XCTAssertFalse (slideLabel.exists)

  slideButton.tap ()
  XCTAssertTrue (slideLabel.exists)
  XCTAssertFalse (typeLabel.exists)
}

Это проверяет, существует ли правильная метка, когда вы нажимаете () на каждой кнопке в сегментированном элементе управления.Запустите тест — все утверждения должны быть успешными.

Тестирование производительности

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

Написать тест производительности очень просто: вы просто помещаете код, который хотите измерить, в замыкание measure () .

~~Чтобы увидеть это в действии, повторно откройте проект HalfTunes и в HalfTunesFakeTests.swift добавьте следующий тест:~~

func test_StartDownload_Performance () {
  let track = Track (
    название: "Ватерлоо",
    исполнитель: "ABBA",
    previewUrl:
      "http://a821.phobos.apple.com/us/r30/Music/d7/ba/ce/mzm.vsyjlsff.aac.p.m4a")

  measure {
    self.sut.startDownload (трек)
  }
}

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

Щелкните Set Baseline , чтобы установить контрольное время. Затем снова запустите тест производительности и просмотрите результат — он может быть лучше или хуже базового. Кнопка Edit позволяет сбросить базовую линию до этого нового результата.

Базовые показатели хранятся для каждой конфигурации устройства, поэтому вы можете выполнять один и тот же тест на нескольких разных устройствах, и каждое из них будет поддерживать разные базовые показатели в зависимости от скорости процессора, памяти и т. Д. Конкретной конфигурации.

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

Охват кода

Инструмент покрытия кода сообщает вам, какой код приложения на самом деле выполняется вашими тестами, чтобы вы знали, какие части кода приложения (еще) не протестированы.

Чтобы включить покрытие кода, отредактируйте действие схемы Test и установите флажок Gather cover for на вкладке Options :

Запустите все тестов ( Command-U ), затем откройте навигатор отчетов ( Command-9 ).Выберите Покрытие под верхним элементом этого списка:

~~Щелкните треугольник раскрытия, чтобы просмотреть список функций и закрытий в SearchViewController.swift :~~

~~Прокрутите вниз до updateSearchResults (_ :) , чтобы увидеть, что покрытие составляет 87,9%.~~

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

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

Чтобы увеличить охват этой функции, вы можете продублировать abbaData.json , а затем отредактировать его, чтобы он приводил к другим ошибкам. Например, измените "результаты" на "результат" для теста, который достигает print ("Ключ результатов не найден в словаре") .

100% покрытие?

Насколько сильно вы должны стремиться к 100% покрытию кода? Погуглите «100% охват модульным тестированием», и вы найдете ряд аргументов за и против этого, а также споры по поводу самого определения «100% покрытия».Аргументы против этого говорят, что последние 10-15% не стоят затраченных усилий. Аргументы в пользу этого говорят, что последние 10-15% являются наиболее важными, , потому что так сложно протестировать. Погуглите «трудно модульное тестирование плохого дизайна», чтобы найти убедительные аргументы в пользу того, что непроверяемый код является признаком более глубоких проблем дизайна.

Куда идти дальше?

Теперь у вас есть отличные инструменты, которые можно использовать при написании тестов для ваших проектов. Я надеюсь, что это руководство по модульному тестированию iOS и тестированию пользовательского интерфейса вселило в вас уверенность в том, что вы сможете протестировать и !

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

~~Вот некоторые ресурсы для дальнейшего изучения:~~

raywenderlich.com Еженедельно

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

Получайте еженедельный дайджест наших руководств и курсов, а в качестве бонуса получите бесплатный углубленный курс по электронной почте!

iOS Automation Testing с использованием UIAutomation framework

~~Home~~
~~Testing~~
- - ~~Back~~
  - ~~Agile Testing~~
  - ~~BugZilla~~
  - ~~Cucumber~~
  - ~~Database Testing~~
  - ~~9000 J2000~~
  - ~~JUnit~~
  - ~~LoadRunner~~
  - ~~Ручное тестирование~~
  - ~~Мобильное тестирование~~
  - ~~Mantis~~
  - ~~Почтальон~~
  - ~~QTP~~
  - ~~Назад~~
  - ~~Центр качества (ALM)~~
  - ~~000~~
  - ~~SAPU Управление тестированием~~
  - ~~TestLink~~
~~SAP~~
- - ~~Назад~~
  - ~~ABAP~~
  - ~~APO~~
  - ~~Начинающий~~
  - ~~Basis~~
  - ~~BODS~~
  - BI
  - ~~BPC~~
  - CO
  - ~~Назад~~
  - ~~CRM~~
  - ~~Crystal Reports~~
  - ~~Crystal Reports~~
  - ~~FICO~~
  - ~~Заработная плата~~
  - ~~Назад~~
  - ~~PI / PO~~
  - PP
  - SD
  - ~~SAPUI5~~
  - ~~Безопасность~~
  - ~~Менеджер решений~~
  - ~~Successfactors~~
  - ~~SAP Tutorials~~
  4
- ~~Web~~
- ~~Apache~~
- ~~AngularJS~~
- ~~ASP.Net~~
- C
- ~~C #~~
- ~~C ++~~
- ~~CodeIgniter~~
- ~~СУБД~~
- ~~JavaScript~~
- ~~Назад~~
- ~~Java~~
- ~~JSP~~
- ~~Kotlin~~
- ~~Linux~~
- ~~Linux~~
- ~~Kotlin~~
- ~~Linux~~
- ~~Perl~~
- ~~Назад~~
- ~~PHP~~
- ~~PL / SQL~~
- ~~PostgreSQL~~
- ~~Python~~
- ~~ReactJS~~
- ~~Ruby & Rails~~
- ~~Scala~~
- ~~SQL~~
- ~~SQL~~
- ~~UML~~
- ~~VB.Net~~
- ~~VBScript~~
- ~~Веб-службы~~
- ~~WPF~~

~~Обязательно учите!~~

- ~~Назад~~
- ~~Бухгалтерский учет~~
- ~~Алгоритмы~~
- ~~Android~~
- ~~Блокчейн~~
- ~~Business Analyst~~
- ~~Создание веб-сайта~~
- ~~CCNA~~
- ~~Облачные вычисления~~
- 00030003 COBOL 9000 Compiler
  9000 Встроенные системы
  00030002 9000 Compiler 9000
  Ethical Hacking
  Учебники по Excel
  Программирование на Go
  IoT
  ITIL
  Jenkins
  MIS
  Сеть
  Операционная система
  Назад
  Управление проектами Обзоры
  Salesforce
  SEO
  Разработка программного обеспечения
  VB A
~~Big Data~~
- - ~~Назад~~
  - ~~AWS~~
  - ~~BigData~~
  - ~~Cassandra~~
  - ~~Cognos~~
  - ~~Хранилище данных~~
  - ~~HBOps~~
  - ~~HBOps~~
  - ~~MicroStrategy~~
  - ~~MongoDB~~

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Ios тестирование: Apple Beta Software Program

Тестирования IOS приложений — Getbug

Безопасность

In-App Purchase (Покупки в приложении)

Правила использования IAP:

Типы подключений

Тестирование на различных скоростях передачи данных

Переключение типов соединения и отсутствие связи:

Публичные сети с авторизацией

Ресурсы устройства

Разрядка батареи

Работа с прерываниями

Тестирование размера экрана

Сворачивание/разворачивание активного приложения

Резюме

«Life.ru» — информационный портал

Производительность iOS 14 по сравнению с iOS 13, iOS 12, iOS 11 в видео-тесте | Смартфоны | Дайджест новостей

Бета-тестирование iPhone-приложений / Хабр

Как установить бета-версию iOS 14 уже сейчас. 3 простых шага

Современный подход к тестированию локализации на iOS / Блог компании Exness / Хабр

Наше приложение

Локализация

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

Автоматическое создание скриншотов

Анализ скриншотов

Резюме

Что еще можно почитать/посмотреть по теме:

Fastlane:

XCTestPlan:

swift-snapshot-testing:

ios-snapshot-test-case:

Display Zoom:

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

Практическое руководство для начинающих

iOS

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

Типы тестирования приложений iOS

Ручное тестирование — Использование устройства

a) Тестирование системы:

b) Тестирование пользовательского интерфейса iOS

c) Тестирование безопасности:

г) Полевые испытания:

Ручное тестирование — с помощью эмулятора

a) Модульное тестирование:

б) Интеграционное тестирование:

c) Тестирование пользовательского интерфейса:

iOS Automation

a) Регрессионное тестирование:

b) BVT Testing:

c) Тестирование совместимости:

d) Тестирование производительности:

Рекомендации по тестированию приложений iOS

iOS Automation Frameworks

# 1) Appium:

# 2) Calabash:

# 3) Эрл Грей:

# 4) Автоматизация пользовательского интерфейса:

# 5) KIF:

Заключение

: руководство и автоматизация

Учебное пособие по модульному тестированию iOS и пользовательскому интерфейсу

Выяснение, что тестировать

Лучшие практики тестирования

Начало работы

Модульное тестирование в Xcode

Создание цели модульного теста

Использование XCTAssert для тестирования моделей

Написание вашего первого теста

Отладка теста

Использование XCTestExpectation для тестирования асинхронных операций

Быстрый отказ

Подделка объектов и взаимодействий

Поддельный ввод от заглушки

Поддельное обновление для Mock Object

Тестирование пользовательского интерфейса в Xcode

Тестирование производительности

Охват кода

100% покрытие?

Куда идти дальше?

raywenderlich.com Еженедельно