Особенности тестирования мобильных продуктов - Мобильное тестирование - особенности и

Это продолжение увлекательной статьи про тестирование мобильных приложений.

...

конвертацию вызовов Open GL ES в вызовы DirectX (растровая отрисовка не удовлетворяет по производительности, а Open GL ES нет в Windows UWP). В этом помогает библиотека ANGLE.

---

ВАЖНО: Интерфейс приложений на основе Qt не является нативным, а только делается похожим на него с помощью стилизации

---

В целом Qt можно было бы рекомендовать как вещь в себе - только готовые модули самого фреймворка плюс платформонезависимые библиотеки на C++. Но в реальных проектах его использовать будет очень непросто - неродной UI, отсутствуют сторонние компоненты (только библиотеки “из коробки”), возникают сложности при сборке и отладке приложения, а также при доступе к нативной функциональности. Из плюсов - высокая производительность кода на C++.

************

Итак, Qt можно рекомендовать для разработки приложений под iOS, Android и Windows UWP только в том случае, если у вас уже имеются большой опыт работы с Qt и понимание непростых системных механизмов. Стоит учитывать, что интерфейс в любом случае может быть только похожим на родной.

3.4 Xamarin

Xamarin сейчас доступен в open source и появился в качестве развития проекта Mono (http://www.mono-project.com), открытой реализации инфраструктуры .NET для Unix-систем. Изначально Mono поддерживался компанией Novell и позволял запускать .NET-приложения в Linux и других открытых ОС.

Для взаимодействия с родными (для C) интерфейсами операционных систем в Mono используется механизм P/Invoke (http://www.mono-project.com/docs/advanced/pinvoke/). На основе Mono были созданы фреймворки MonoTouch и MonoDroid, которые затем переименовали в Xamarin.iOS и Xamarin.Android, и теперь вместе называют “классическим Xamarin” (Xamarin Classic).

Классический Xamarin предоставляет полный доступ к нативным API, то есть можно создавать нативные приложения iOS/Android с помощью C# без единой строчки на Objective C и Java. Нативные библиотеки подключаются через механизм байндинга (Native Library Binding). Взаимодействие с ОС происходит через мост и механизм оберток (wrappers), однако нет необходимости сериализовать данные, так как осуществляется автоматический маршалинг и есть возможность прямой передачи ссылок между средами Mono Managed и Native. Можно также использовать большое количество .NET-библиотек из NuGet.

Инфраструктура .NET/Mono предполагает использование JIT по аналогии с Java, когда приложение компилируется в промежуточный байт-код и уже потом интерпретируется во время исполнения. Но из-за ограничений iOS нет возможности использовать JIT, и поэтому байт-код Xamarin.iOS-приложений компилируется в нативный бинарный и статически линкуется вместе с библиотеками. Такая компиляция называется AOT (Ahead Of Time) и является обязательной в Xamarin.iOS. В Xamarin.Android же помимо AOT доступен и режим JIT, когда виртуальное окружение Mono работает параллельно с Dalvki/ART и интерпретирует код во время исполнения.

Как видим, общая база кода между платформами ограничивается бизнес-логикой и механизмами работы с данными. К сожалению, UI и платформенную функциональность приходится реализовывать отдельно для каждой платформы. В результате шарить можно не более 30%-40% от общей базы кода мобильных приложений. Для достижения большего результата необходимо использовать Xamarin.Forms, о котором мы расскажем в Главе 3.5.

Ключевым преимуществом классического Xamarin является использование языка C# для всего кода и, как следствие, разработчиков, которые уже хорошо знакомы с .NET. Также обязательным является хорошее знание и понимание механизмов iOS/Android, их классовых моделей, архитектур, жизненных циклов объектов и умение читать примеры на Objective C и Java.

---

ВАЖНО: Производительность C#-кода сопоставима с производительностью нативного кода в iOS/Android, но при взаимодействии с ОС используется мост, который может замедлять приложение при неэффективном использовании

---

Приложение на Xamarin.iOS/Xamarin.Android обычно состоит из shared (общей) части, которая упаковывается в .NET-библиотеку и платформенной части, которая имеет полный доступ к API, включая нативный пользовательский интерфейс. В платформенной части содержится описание экранов, ресурсы, стили, шрифты - практически 100% структура нативного проекта на Objective C или Java, только на C#. Также есть возможность подключать код на C# в нативных проектах с помощью Embeddinator-4000 (https://mono.github.io/Embeddinator-4000).

Классический Xamarin является зрелым решением и обеспечивает максимально близкий к нативному опыт разработки для C#-программистов и использованием привычных инструментов вроде Visual Studio.

************

Итак, если стоит задача реализовать полностью нативное приложение и при этом имеются опытные C#-разработчики, то Xamarin может стать хорошим выбором для широкого спектра задач, как больших (более 40), так и маленьких (до 10).

3.5 Xamarin.Forms

Если у вас стоит цель максимизировать общую базу кода, то классический Xamarin здесь явно проигрывает всем остальным фреймворкам (PhoneGap, ReactNative, Qt и их аналогам). Это понимали и в самом Xamarin, поэтому выпустили решение, позволяющее использовать единое описание UI и простые механизмы доступа к платформенным фичам - Xamarin.Forms.

Библиотека Xamarin.Forms работает поверх описанного ранее классического Xamarin и фактически предоставляет механизмы виртуализации пользовательского интерфейса и дополнительную инфраструктуру.

Xamarin.Forms (XF) решает своего рода задачу «последней мили», предоставляя единый API для работы с пользовательским интерфейсом в разных операционных системах (iOS, Android, Windows UWP/WPF, Linux Gtk#, Mac OS X, Tizen). При этом сам интерфейс остается полностью родным.

Для того, чтобы лучше понять, как работает XF, давайте рассмотрим простую кнопку. Одним из базовых механизмов являются рендереры (renderers), благодаря которым при отображении кнопки Xamarin.Forms фактически на экран добавляется нативный контрол, а свойства XF-кнопки динамически пробрасываются в свойства нативной кнопки на каждой платформе. В ReactNative используются похожие механизмы.

Общая (shared) часть на Xamarin.Forms обычно реализуется в виде библиотеки (Portable/PCL или .NET Standard) и имеет доступ к базе компонентов в NuGet. Платформенная часть реализуется на базе Xamarin Classic и имеет полный доступ к API, а также возможность подключения сторонних библиотек. При этом общий процент кода между платформами обычно доходит до 85%. Также Xamarin.Forms можно использовать в режиме Embedded для создания отдельных экранов и View внутри приложений на классическом Xamarin.iOS и Xamarin.Android.

Если вам будем достаточно уже доступных в Xamarin.Forms компонентов и плагинов, то не потребуется глубоких знаний в iOS/Android/Windows. Однако для более сложных сценариев (свои контролы, полная реализация дизайна в режиме pixel perfect) все же потребуется хорошее знание ОС и ее механизмов, плюс понимание Xamarin.Forms.

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

************

Итак, Xamarin.Forms можно рекомендовать для быстрой разработки прототипов на C#, однако Xamarin.Forms также можно использовать для корпоративных и бизнес-приложений любого масштаба (100 и более экранов). Внешний вид, производительность и поведение приложений будет полностью нативным, но стоит не забывать об эффективном взаимодействии с операционной системой через мост.

Особенности тестирования мобильных продуктов

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

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

• Мобильное устройство – это система, которая не обладает мощной начинкой. Таким образом, он не может работать как персональный компьютер.
• тестирование мобильных приложений проводится на мобильных телефонах (Apple, Samsung, Nokia), в то время как настольное приложение тестируется на центральном процессоре.
• У мобильных устройств бывают разные разрешения. Размер экрана мобильного телефона меньше, чем у настольных.
• Выполнение и прием вызовов является основной задачей телефона, поэтому приложение не должно вмешиваться в эту важную функцию.
• Широкий спектр конкретных операционных систем и компонентных конфигураций: Android, iOS, BlackBerry.
• Операционная система мобильного телефона быстро устаревает.
• Мобильные устройства используют сетевые подключения (3G, 4G, Wi-Fi), широкополосное подключение к настольному ПК или Wi-Fi.
• Мобильные устройства постоянно осуществляют поиск сети. Вот почему вы должны протестировать приложение с разной скоростью передачи данных.
• Инструменты, которые хорошо подходят для тестирования настольных приложений, не полностью подходят для тестирования мобильных приложений.
• Мобильные приложения должны поддерживать несколько входных каналов (клавиатура, голос, жесты и т. д.), мультимедийные технологии и другие функции, повышающие их удобство использования.

Принцип 1: Юзер экпиренс

Внешний вид и удобство использования важнее функционала, тестировать нужно все

Принцип 2: Постоянная мобильность

Главное отличие мобильного от десктопного ПО заключается в том, что с айфоном вы передвигаетесь, тщетно ловите вайфай в столовых ваших вузов (совершая характерные движения руками), бегаете и вообще по максимуму загружаете все возможные сенсоры движений, что китайские умельцы встроили в него. Забывать об этом смерти подобно. Кто-то может сказать, что глупо бегать по офису, меняя ориентации экрана и теряя-восстанавливая коннект. На это у меня есть 2 контр-примера из жизни:

• Крэш в приложении при попытке восстановить приложение из бэкграунда с предварительной сменой ориентации экрана;
• Крэш в приложении при “потряхивании” девайса в момент совершения этим девайсом фотосъемки (приложение изначально создавалось для создания фото).

Принцип 3: Ловля вай-фая на живца

• Большая часть современных приложений, так или иначе, использует сеть. Далеко не всегда это “полный коннект”. Поэтому обязательно необходимо тестировать приложение как минимум 4-мя способами:
• Позитивный кейс (наличие отличной постоянной связи);
• Наличие постоянной неотличной связи;
• Отсутствие связи;
• Потеря связи.

• Большинство пользователей вряд ли увидят ваши крэшы, но могут перестать пользоваться приложением, если оно плохо грузит и сохраняет данные при их (пользователей) проблемном коннекте. На случай отсутствия связи должны быть отображены хотя бы какие-то плейсхолдеры (чтобы пользователь мог понять, что приложение не может прогрузить данные сейчас). Ну и конфетка для тестера – потеря связи. Пользователи будут сталкиваться с этим постоянно, и тут самое важное: избежать по возможности потери данных.

Принцип 4: Прерывания (интерапшн)

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

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

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

Принцип 5: Особенности операционных систем и железа

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

• Андроид и ЯблокоОсь существенно отличаются от десктопных систем. Активности (и их стэк), интенты, броадкаст ресиверы, манифест файл (с указанием permissions и user features), доступ к ресурсам, кэш и данные приложений – все это и многое другое нужно хотя бы бегло изучить для того, чтобы понимать, как ваше приложение работает в данной конкретной среде, что может привести к его (приложения) отказу или потере данных. Отсюда вытекает тестирование перехода между состояниями, тестирование для нахождения утечек памяти и прочее. Все это необходимо для полноценного обеспечения качества приложения.
• Прогресс не стоит на месте, но железо смартфонов все еще сильно ограничено по сравнению с настольными системами. Особенно важно то, сколько ваше приложение занимает оперативной памяти, при каких условиях система автоматически “выпилит” его из этой самой памяти, как приложение будет себя вести в этой ситуации.

Принцип 6: Человеческий фактор

Если приложение рассчитано на широкую аудиторию, будьте готовы к тому, что куча людей, бесконечно далеких от разработки ПО, будет вести себя совершенно по-разному с вашим приложением. Тут важно понимать, что мы не можем просчитать все возможные случаи использования приложения всеми криворукими пользователями. Но проверить, что приложение корректно выполняет весь свой функционал на основных юз-кейсах мы обязаны. Неплохо также обезопасить себя, пробежавшись по приложению в качестве пользователя-дурачка, тыкая во все подряд, открывая и закрывая активности, не дожидаясь загрузки данных и т.д. Проблема с “замыленным глазом” решается путем привлечения в процесс ваших девушек, друзей и родственников. Просто дайте им приложение в руки и посмотрите, как они будут им пользоваться. Это даст вам примерную (насколько примерную зависит, конечно, от величины выборки) картину того, что следует тестировать в первую очередь и на что обратить внимание.

Принцип 7: Соблюдейние гуйдланов от андроид, аос, майкрософт

как выглядят кнопки

как приложение должно быть разработано, как приложение должно использовать ресурсы и тд

как используются движения -тач, свайп, датчиков

шаринг данных, авторизация через сторонние сервисы и т.д.

Принцип 8

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

отключенного геоположения, запрет обнолвлений, изменение ориентации экрана, и т.п.

Этапы тестирования мобильных приложений

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

1. Тестирование документации

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

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

На этом этапе создаются и анализируются требования (спецификация, PRD), план тестирования, тестовые сенарии, матрица отслеживания.

2. Функциональное тестирование

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

• Тип приложения, определяемый его бизнес-функциональностью (социальные сети, банковское дело, образование, заказ и доставка продуктов питания, билеты, игровая индустрия и т. д.).
• Целевая аудитория (компании, пользователи, образовательная среда и т. д.).
• Каналы распространения (Google Play, магазин приложений и т. д.)

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

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

Тестирование полей

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

Тестирование функциональности

• Убедитесь, что заявленная цена и контент соответствуют полученной пользователем информации.
• Убедитесь, что пользователь может выполнять типичные операции: покупка, добавление товаров в корзину, заказ товаров и т. д.
• Убедитесь, что приложение поддерживает платежные операции через платежные системы, такие как Visa, Mastercard, Paypal и т. д.
• Проверьте восстановление покупки независимо от устройства, но с привязкой к учетной записи.

Тестирование прерываний

• Входящие и исходящие звонки, SMS и MMS.
• Разрядка / снятие батареи.
• Отключение и подключение сети / Wi-Fi.
• Отсоединение и подключение SD-карты.
• Зарядка устройства.

Постоянное тестирование отзывов пользователей

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

Тестирование обновления

• Все пользовательские данные сохраняются после обновлений.
• Убедитесь, что ход обновления отображается правильно.
• Убедитесь, что обновления поддерживаются более старыми операционными системами.
• Тестирование различных способов установки обновлений (Wi-Fi, Bluetooth, USB).

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

• Отсутствие места для установки или запуска приложения.
• Утечка памяти. Обратите внимание на окна с большой информацией и задачами с длинным рабочим процессом.
• Установка / замена приложения на SD-карте.
• Отсутствие некоторых функций, поддерживаемых приложением (3G, SD-карта).
• Убедитесь, что установленное приложение не мешает нормальной работе других приложений и не использует их память.

Дополнительное тестирование

• Тестирование правильности подключения / разъединения игроков, подключения игроков через разные сети.
• Убедитесь, что сообщения об ошибках верны и уместны.
• Проверьте подключение к аналитическим инструментам, таким как Google Analytics.
• Тестирование энергопотребления.
• Проверьте необходимые параметры правильной работы с социальными сетями – «Поделиться», «Опубликовать», «Навигация».

Некоторые полезные инструменты для тестирования функциональности мобильных приложений: Appium, Selendroid, Robotium, Ranorex.

3. Юзабилити-тестирование

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

• удобство
• КПД
• эффективность

Рассмотрим простой контрольный список для проведения юзабилити-тестирования мобильных приложений:

• Убедитесь, что кнопки имеют нормальный размер и помещены в одну область экрана.
• Убедитесь, что приложение работает в многозадачном режиме, когда это необходимо.
• Проверьте навигацию важных модулей приложений.
• Убедитесь, что значки и изображения выглядят естественно в среде приложения.
• Убедитесь, что цвет кнопок, которые выполняют одну и ту же функцию, одинаковый.
• Текст должен быть простым, понятным и видимым для пользователя. Можно читать короткие предложения и параграфы.
• Определите оптимальный размер шрифта.
• Обеспечьте правильную работу системы Zoom-in and Zoom-out.
• Проверьте, что контекстные меню не перегружены.
• Убедитесь, что приложение может быть прервано в любом состоянии и что оно возобновляет работу в том же состоянии.
• Убедитесь, что компоненты приложения синхронизированы с действиями пользователя.
• Убедитесь, что пользователь может вернуть или отменить действие, если он нажал неправильную кнопку.
• Убедитесь, что скорость ответа элемента достаточно высока.

Некоторые полезные инструменты для тестирования удобства использования мобильных приложений: Zoom, Loop11.

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

Тестирование пользовательского интерфейса (UI) выполняется для обеспечения соответствия графического пользовательского интерфейса вашего приложения спецификациям:

• Обеспечить соответствие стандартам пользовательского интерфейса.Соответствие стандартным разрешениям экрана: 640 × 480, 800 × 600, 1024 × 768, 1280 × 800, 1366 × 768, 1400 × 900, 1680 × 1050.
• Протестируйте работоспособность приложений на разных устройствах.
• Проверьте основные элементы дизайна: кнопки, значки, цвета, ссылки, шрифты, размеры шрифта, макет, текстовые поля, форматирование текста, ярлыки, титры, кнопки, списки и т. д.
• Убедитесь, что реклама не перекрывает кнопки управления приложениями.
• Убедитесь, что у рекламы есть доступная кнопка закрытия.
• Проверьте отображение всех элементов с ориентацией на портретную и альбомную страницу.

Полезные инструменты для тестирования интерфейса мобильных приложений: FitNesse, iMacros, Jubula, LoadUI.

5. Тестирование совместимости

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

Вы должны обратить внимание на следующие моменты:

• Конфигурация ОС
• Конфигурация браузера
• Конфигурация базы данных
• Конфигурация устройства
• Конфигурация сети

Кросс-платформенное тестирование помогает тестировать мобильное приложение на разных ОС: Windows, iOS, Android и BlackBerry и т. д.

Кросс-браузерное тестирование позволяет обеспечить правильную работу приложения в разных конфигурациях браузера: Mozilla Firefox, Google Chrome, Opera Mini и т. д.

Тестирование базы данных предназначено для проверки правильной работы вашего приложения в разных конфигурациях базы данных: Oracle, DB2, MySql, MSSQL Server, Sybase.

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

1. Тип устройства: смартфон, планшет и т. д.
2. Конфигурация устройства: ОЗУ, тип процессора, разрешение экрана, емкость аккумулятора и т. д.
3. Тестирование конфигурации сети выполняется для обеспечения правильной работы в различных сетевых конфигурациях (GSM, TDMA) и стандартах (2G, 3G, 4G).

Советы по тестированию совместимости мобильных приложений:

• Создайте матрицу покрытия (таблицу, в которую вводятся все возможные конфигурации).
• Приоритет конфигурации.
• Проверяйте каждую конфигурацию, шаг за шагом, в соответствии с установленными приоритетами.

Полезные инструменты для проверки совместимости мобильных приложений: BrowserStack, CrossBrowserTesting от Smart Bear, Litmus, Browsera, Rational Clearcase от IBM, Ghostlab.

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

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

Основные цели тестирования производительности:

• Проверка времени отклика приложения на различные типы запросов, чтобы убедиться, что приложение работает в соответствии с требованиями для нормальной загрузки пользователя. (Нагрузочное тестирование).
• Тестирование работоспособности приложения при нагрузках, превышающих количество пользователей в несколько раз. (Стресс-тестирование).
• Изучите работоспособность приложения для долговременной работы при нормальной нагрузке. (Стабильность).
• Проверяйте работу в условиях «расширенной» базы данных в обычное время. (Тестирование объема).
• Определите количество пользователей, которые могут одновременно работать с приложением. (Параллельное тестирование).

Советы по тестированию производительности вашего мобильного приложения:

• Определите, работает ли приложение в разных сетевых условиях.
• Найдите те участки приложений, которые снижают производительность приложений.
• Оцените способность приложения справляться с определенными объемами нагрузки.
• Убедитесь, что время ответа приложения соответствует требованиям.
• Проверьте стабильность приложения в условиях “жесткой” нагрузки пользователей.
• Обеспечьте производительность приложения, если оно работает в условиях непостоянного подключения к Интернету.

Полезные инструменты для тестирования производительности мобильных приложений: NeoLoad by Neotys, Apteligent (ранее Crittercism), New Relic.

7. Тестирование безопасности

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

• Убедитесь, что данные пользователей приложения (логины, пароли, номера банковских карт) защищены от сетевых атак автоматизированных систем.
• Убедитесь, что система безопасности приложений требует надежного пароля и не позволяет злоумышленнику получать пароли других пользователей.
• Убедитесь, что приложение не предоставляет доступ к конфиденциальному содержимому или функциям без надлежащей проверки подлинности.
• Защитите приложение и сеть от DoS Attacks.
• Защитите приложение от вредоносных атак на клиентов.
• Предотвратите возможные вредоносные последствия кэширования файлов.
• Изучите файлы пользователей и предотвратите их возможные негативные последствия.
• Анализ взаимодействия системных файлов, выявление и исправление уязвимостей.

Полезные инструменты для проверки безопасности мобильных приложений: сообщества CS, OWASP Zed Attack Proxy, Veracode, Google Nogotofail и SQL Map.

8. Тестирование восстановления

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

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

9. Тестирование локализации

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

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

Ubertesters, eggPlant могут быть полезны.

10. Тестирование изменения

Итак, вы прошли все упомянутые этапы и обнаружили ошибки. Поэтому некоторые изменения были внесены в код вашего приложения.

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

Убедитесь, что новые изменения не привели к появлению новых ошибок. (Регрессионное тестирование).

Некоторые полезные инструменты для тестирования, связанные с изменением вашего приложения: Appium, Robotium, Ranorex.

11.Бета-тестирование

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

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

Люди, которые имеют опыт работы с приложениями подобного типа, еще лучше, с предыдущей версией приложения, выбраны для роли бета-тестеров.

Перед бета-тестированием своего мобильного приложения вы должны обратить внимание на следующие факторы:

• Ряд участников тестирования.
• Продолжительность тестирования.
• Демографический охват.
• Стоимость тестирования.

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

Некоторые популярные платформы для бета-тестирования мобильных приложений: HockeyApp, Ubertesters, TestFlight.

12. Сертификационное тестирование

Существуют определенные правила организации установочного файла (.apk) и правил проектирования приложений для каждого хранилища приложений. Тестирование сертификатов подтверждает, что приложение соответствует требованиям самых популярных магазинов, таких как Google Play, App Store и Windows Phone.

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

Android:

1. Файл установки для приложения (.apk) соответствует политикам программы.
2. Приложение соответствует требованиям UIG.
3. В приложении нет вирусов. Рынок Android полуавтоматически проверяет приложение на наличие вирусов и может блокировать вашу учетную запись, если обнаруживает их.
4. Вы должны следовать порядку контроля версий в случае публикации обновленной версии вашего приложения.

IOS:

1. Приложение соответствует требованиям Руководства по пользовательскому интерфейсу.
2. Приложение должно иметь уникальное имя.
3. Вам необходимо предоставить ссылку для обратной связи с разработчиком.
4. Приложение должно быть помещено в определенную конкретную категорию.
5. App Store проверяет приложение на совместимость.
6. Приложение не содержит запрещенных материалов, непредвиденных задержек в работе или повторения существующих функций.

Windows Phone:

1. Приложение соответствует требованиям к сертификации приложений.
2. Четкое описание аппаратных и сетевых требований.
3. Функции, упомянутые в описании или показанные на снимках экрана, полностью реализованы

Советы по тестированию мобильного приложения

Давайте систематизируем наши знания и попытаемся определить основные советы для тестирования мобильных приложений.

1. Изучите приложение,

продолжение следует...

Продолжение:

Часть 1 Мобильное тестирование - особенности и этапы. Архитектура мобильных приложений
Часть 2 Особенности тестирования мобильных продуктов - Мобильное тестирование - особенности и
Часть 3 Тестирование мобильного приложения с помощью EasyQA - Мобильное тестирование -

См.также

• Траблшутинг
• Качество программного обеспечения
• web-тестирование , web тестирование , вебтестирование ,

Надеюсь, эта статья об увлекательном мире тестирование мобильных приложений, была вам интересна и не так сложна для восприятия как могло показаться. Желаю вам бесконечной удачи в ваших начинаниях, будьте свободными от ограничений восприятия и позвольте себе делать больше активности в изученном направлени . Надеюсь, что теперь ты понял что такое тестирование мобильных приложений, архитектура мобильных приложений, mobile-тестирование и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.