Тестирование мобильных приложений является затратным по времени и стоимости, но без него никак, если вы хотите добиться высокого уровня удовлетворенности клиентов. Важно, чтобы у всех ваших пользователей были хорошие впечатления от работы с приложением. Если вы его плохо протестируете, пользователи это сразу заметят. Клиенты не любят, когда на них экспериментируют — если в приложении произойдет сбой, они просто уйдут и не вернутся.
Представим, что ваш разработчик написал отличный код и не сделал ни одной ошибки. Несмотря на это, приложение все равно нужно тестировать, потому что ваша цель состоит не в том, чтобы найти ошибки разработчика, а в том, чтобы понять насколько приложение качественное. Работает ли оно? Все ли функции реализованы как ожидалось? Соответствует ли оно потребностям клиентов и смогут ли они им пользоваться постоянно?
В этой статье я расскажу о различных подходах к мобильному тестированию и затрону факторы, которые необходимо учитывать при создании стратегии тестирования вашего приложения.
Тестирование на мобильных устройствах связано с определенными специфическими сложностями. Рассмотрим основные из них.
Парк устройств
Парк устройств, возможно, является самым большим препятствием для мобильного тестирования. Клиенты могут использовать десятки тысяч разных устройств для загрузки вашего приложения. Все эти устройства нужно каким-то образом учитывать при тестировании. Если добавить сюда многообразие версий мобильных операционных систем, то получится очень большая выборка. Ограничение этой выборки приводит к рискам появления сбоев и отказов в работе приложения у части клиентов. Поэтому необходима надежная методика выбора устройств и операционных систем. Что касается самих устройств, то есть всего три варианта:
- использовать реальные устройства,
- использовать эмуляторы,
- использовать некоторую комбинацию из реальных устройств и эмуляторов.
С точки зрения тестирования у реальных устройств есть преимущества. Они обладают всеми ограничениями и особенностями ОС, аппаратных компонентов и прошивки, с которыми сталкиваются ваши клиенты. Однако, тестирование на мобильных устройствах может быть очень дорогостоящим. Помимо стоимости самих устройств, необходимо учитывать также затраты на связь. Кроме того, устройства необходимо где-то хранить и обновлять.
Эмуляторы использовать проще, так как вы можете менять телефоны и планшеты для тестирования просто загружая новый профиль устройства. Эмуляторы, с точки зрения мобильного приложения, ведут себя точно так же, как и реальные устройства. Они запускаются на более мощном оборудовании (компьютеры и серверы, а не телефоны) и изначально разработаны для тестирования, поэтому в них содержатся встроенные средства диагностики и профилирования на уровне протоколов, что, конечно, очень удобно для тестировщиков.
Большим недостатком эмуляторов является отсутствие в них специфических ограничений, странностей и особенностей, которыми обладают только реальные устройства. Эмулятор устройства не может выполнить рендеринг изображения, который совпадал бы с точностью до пикселя с реальным устройством. Также, поскольку процессорная мощность компьютера, на котором запускается эмулятор — это важный атрибут, который не совпадает с мощностью процессора реального устройства – могут быть проблемы с временем отклика приложения, которые тестировщик не обнаружит. Кроме того, эмулятор устройства не чувствителен к внешней среде. Обычно это даже хорошо, однако, если вы захотите проверить, как работает приложение в конкретном месте, например, на переполненном стадионе, необходимо применять только реальные устройства.
К счастью, нет причин ограничиваться только реальными или эмулируемыми устройствами. Хорошим вариантом является микс из тех и других. Можно начать тестирование на эмуляторах, так как это быстрее и сразу даст результат. Например, на ранних стадиях разработки точность рендеринга имеет незначительное значение. Реальные устройства можно добавить на более поздних стадиях жизненного цикла, для валидации работы приложения и проверки выполнения всех требований к нему.
Сеть: региональные проблемы
В мире существует более 400 операторов мобильной связи. Каждый оператор поддерживает множество сетевых технологий, таких как LTE, CDMA, GSM. Часто операторы поддерживают местные и менее известные сетевые стандарты, например, IDEN, FOMA и TD-SCDMA. В каждой сети есть своя уникальная инфраструктура, обеспечивающая инкапсуляцию низкоуровневых протоколов мобильной сети в TCP-IP, который нужен для работы мобильного веба. Каждый оператор использует собственные системы для выполнения инкапсуляции, поэтому у всех она работает по-разному. Ну и напоследок, большинство операторов используют прокси, чтобы контролировать, когда, кто и зачем получает доступ к конкретным сайтам. Эти прокси-сервера могут ограничивать потоки данных, курсирующие между вашим сервером и тестовым клиентом. Некоторые прокси разрешают доступ с телефонов только к тем сайтам, которые прошли определенную проверку. Другие прокси используют «транскодеры» для того чтобы автоматически уменьшить фиксированный веб-контент для отображения на мобильных устройствах. Как видите, проблем хватает.
Размышляя о проблемах тестирования, связанных с сетью, не забудьте о проблемах с физическим местоположением устройств. Очевидно, что для полноценного тестирования в сети конкретного оператора, вам придется подключиться к этой сети. Для тестирования в сети МТС – вы должны быть в России, а для AT&T – в США.
Очевидно, что путешествия в места покрытия конкретных операторов, у которых должно работать ваше приложение, это довольно высокие дополнительные затраты. Тем не менее, эту проблему тоже необходимо учитывать при подготовке стратегии мобильного тестирования.
Сеть в режиме «bypass»
Исключив низкоуровневую сеть (режим «bypass»), вы можете подключиться к серверу сразу по TCP/IP и, таким образом, игнорировать во время тестов этап преобразование данных из GPRS. Поскольку большинство реальных устройств так не могут, для работы в режиме «bypass» нужно использовать эмуляторы. Эмуляторы придется поискать, так как далеко не все они умеют работать в режиме «bypass» через интернет, а без этого тестирование будет нереалистичным. Некоторые эмуляторы умеют подключаться к прокси-серверу оператора (только если он доступен из Интернета), чтобы сделать тестирование более реалистичным. У некоторых операторов есть доступ к веб-прокси через интернет (только для клиентов), сделанный для тестирования.
Преимуществом тестирования в режиме сети «bypass» является отсутствие платы за мобильную связь. Ну и, поскольку вы используете эмулятор, у вас есть хороший набор инструментов для диагностики.
И все же, чаще всего, перевод сети в режим «bypass» не позволяет протестировать важные вещи, такие как задержки сети и специфическое поведение сетевых компонентов, таких, например, как прокси. К тому же, такое тестирование проводится только на эмуляторах и поэтому в ходе тестов не будут учтены особенности реального устройства.
Реальные сети
Тестирование в реальных сетях можно проводить как на физических устройствах (с учетом всех описанных проблем), так и на эмуляторах. Многие эмуляторы поддерживают работу через модемы, позволяющие подключиться в реальную сеть оператора связи, но опять же, это не отменяет необходимости физического перемещения модема в зону покрытия провайдера. Есть и третий вариант.
Третий вариант – использование реальных устройств в облаке. Этот тип тестирования подразумевает доступ к удаленному устройству, подключенному к специальному блоку управления с антенной. Блок управления подключен непосредственно к экрану и устройству ввода мобильного устройства, что позволяет нажимать кнопки и делать скриншоты экрана. Связка блок + смартфон доступна через интернет, такое решение позволяет тестировщику управлять устройством удаленно при помощи мышки и клавиатуры, наблюдая за тем, что происходит на экране. Это элегантное решение позволяет тестировать устройства в реальных сетях связи.
Удаленные решения часто обладают способностью записывать и воспроизводить тесты, что можно использовать для регрессионного тестирования и автоматизации приемочных тестов.
Поскольку устройств много, создавать удаленные мобильные решения может быть дорого. Их можно брать в аренду у специализированных облачных провайдеров. Для этого, обычно, вам просто нужно зарегистрироваться на их сайте и далее оплачивать время использования конкретных мобильных устройств в необходимых сетях.
Автоматизация тестов на мобильных устройствах
Выполнять тесты можно вручную или автоматизировано. Тест-кейс может быть описан в виде документа или таблицы. Он попадает к тестировщику, который либо выполняет его вручную, фиксируя результат в виде статуса pass/fail, либо запускает автоматизированные скрипты, которые выполняют тест мобильного приложения на устройстве и записывают результат.
Поскольку устройств много и у них разный пользовательский интерфейс, авто-тесты должны быть абстрагированы от конкретного устройства, иначе их не получится использовать. Например, если ваш скрипт заточен под нажатие конкретных кнопок и свайпы в приложении на iPhone, то он ни при каких обстоятельствах не выполнится на Samsung, потому что интерфейс совсем другой. К счастью, большинство инструментов автоматизации тестирования мобильных приложений на реальных устройствах позволяют писать высокоуровневые скрипты, которые работают на уровне текста, изображений или объектов. Большинство эмуляторов устройств, также, способны выполнять авто-тесты, написанные на высокоуровневом языке, независимо от эмулируемого устройства.
При использовании автоматизации, разработка скрипта, как правило, обходится дороже, чем запуск теста вручную. Но если вы запускаете тесты постоянно, то с каждым новым запуском увеличивается экономия времени и трудозатрат. При определенном количестве запусков, автоматизированный скрипт окупает начальные затраты на его разработку.
В завершение, нужно отметить, что многие инструменты автоматизации тестирования поддерживают так называемые функции «spider» или «crawl». Иногда это позволяет протестировать целый сайт при помощи одной команды. Эти функции не предназначены для выполнения сложных и комплексных транзакций, но могут сэкономить много времени, так как способны самостоятельно обходить сайт или приложение и проверять каждую страницу на наличие дефектов и находить несоответствия устройств.
Рекомендации
Теперь, когда вы узнали больше о проблемах, связанных с мобильным тестированием, осталось понять, как использовать эту информацию. Какой должна быть ваша стратегия тестирования мобильных приложений?
Не имеет большого смысла выбирать какой-то один инструмент или подход, потому что тогда вам придется смириться с большим количеством компромиссов. Лучше всего использовать комбинацию из разных инструментов и техник, наиболее подходящих для ваших задач. Подводя итог, приведем несколько общих рекомендаций:
- Не бойтесь использовать эмуляторы устройств. Эмуляторы позволяют быстро и недорого провести основные тесты и использовать встроенные средства протоколирования и диагностики. При выборе эмуляторов, в зависимости от ваших целей, обращайте внимание на наличие таких опций как возможность проводить тесты в реальных сетях (через модем), возможность тестирования режиме «bypass» (исключая из тестирования сеть оператора), наличие подходящего вам языка для написания скриптов. Проверьте, можно ли на этом эмуляторе писать высокоуровневые, независимые от устройства, авто-тесты. Наконец, убедитесь, что смена профиля устройства выполняется без длительных задержек.
- Зарегистрируйтесь в облачных сервисах с реальными устройствами. Вам это поможет для проведения тестов в удаленной сети, к которой у вас нет доступа. Наличие такого аккаунта точно не будет лишним, и позволит сэкономить время, когда нужно будет провести тесты на конкретных устройствах в конкретной сети.
- Автоматизируйте все, что можно. Это существенно сэкономит время, поможет провести намного больше тестов и увеличить тестовое покрытие. Идеально, если фреймворк автоматизации позволит работать с реальными устройствами и эмуляторами одновременно.
Автор: Валера
