Файл: Этапы разработки, тестирования и ввода в эксплуатацию мобильных приложений (Особенности тестирования мобильных приложений в целом).pdf

Введение

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

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

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

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

- около 54 % пользуются скаченными приложениями;

- столько же людей заходят на сайты через мобильный телефон;

- социальными сетями через телефон пользуется около 38 %;

- 35 % людей пользуются мобильными играми;

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

В ходе поставленной цели будут решены следующие задачи:

- рассмотрены теоретические основы разработки мобильных приложений: их этапы, особенности тестирования;

- рассмотрено создание мобильного приложения с Nokia Qt SDK.

Курсовая работа состоит из введения, двух глав, заключения и библиографии.

Глава 1 Теоретические основы разработки мобильных приложений

1.1 Этапы разработки мобильных приложений

Определение цели

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

---

Если приложение само по себе продукт (калькулятор, например), то при его разработке нужно задаться двумя вопросами: зачем оно потребителю, и как потребитель будет им пользоваться?^[1]

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

Анализ требований

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

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

Найм лучшего дизайнера и опытного разработчика

Результаты этапа анализа (концепция продукта, спецификация требований) являются входящей информацией к следующему этапу — проектированию.^[2] Мы выполняем проектирование двух составляющих приложения: графический интерфейс и структура программного кода приложения. На этом этапе создаются каркас графического интерфейса (wireframes), карта экранов (screenflow), прототип низкой детализации, а также пользовательские сценарии (use cases) и дизайн кода приложения (software architecture). 

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

---

Критика дизайна со стороны юзабилити-специалиста

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

Юзабилити-исследование^[3] — супер-шаг быстрого выявления и устранения проблем, в частности, «задизайнивания». Это когда вместо упрощения реализации сценариев в погоне за эстетикой процесс решения задач усложняется. Результат — потеря эффективности. Это значит, что при тестировании меньшее количество пользователей поймет, как выполнить те или иные задачи. И среднее время решения задач, и количество успешных попыток выполнения сценариев будут не лучшими. С такой проблемой мы столкнулись в проекте «Мой Билайн» — функциональная кнопка, расположенная в соответствии с гайдами справа в углу, клево выглядела, но пользователи ее не замечали. Пришлось перемещать ее в центр экрана. 

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

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

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

Анализ безопасности

Разработкой приложения должны заниматься специалисты, знакомые с понятием SA (security assurance).

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

По мере того, как создается мобильное приложение, мы «облепляем» код модульными тестами (unit test) и постоянно и автоматически подвергаем уже разработанный функционал тестированию. Это позволяет всегда быть уверенными в качестве разработанного кода.

---

По завершении этапа разработки необходимо проверить работу приложения на соответствие всему набору тест-кейсов, которые базируются на требованиях, то есть проверить работу приложения на соответствие исходным требованиям. После успешного прохождения через службу профессиональных QA-инженеров (quality assurance) приложение признается готовым к публикации. В этот момент мы сообщаем PR-службе дату поставки готовой сборки приложения — самое время сосредоточиться на подготовке текстовых и графических материалов: описаний, ключевых слов, скриншотов, видеопрезентаций.

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

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

Чтобы понять особенности тестирования мобильных приложений следует принимать во внимание моменты, принципиально отличающие мобильные приложения от десктопных: специфичность ОС для мобильных платформ, различные компании-изготовители устройств и конфигурации комплектующих, функциональность устройств как коммуникаторов и т.п^[4].

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

Тестирование обновлений – частые обновления операционной системы (относительно десктопов) приводят к необходимости обновлять приложение. Обновление должно проходить просто и не требовать от пользователя специфических знаний. Следует так же проверять различные возможные пути установки приложения (Wi-Fi, 3G, установка с ПК, на SD).

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

---

Тестирование удобства пользования (usability). Этот вид тестирования является одним из важных, так как в условиях высокой конкуренции юзабилити приложения входит в список основных параметров, влияющих на популярность продукта. Позволяет выявить части приложения, которые недостаточно привлекательны или вызывают затруднения в навигации или использовании на сенсорных экранах. Следует так же убедиться, что модель потребления ресурсов приложением соответствует целевой аудитории. Например, приложения-напоминания не должны вызывать чрезмерное потребление энергии. Зачастую это тестирование проводится в виде бета-тестирования.

Нагрузочное тестирование подразумевает наблюдение за использованием памяти и системных ресурсов; кроме того, нагрузочное тестирование позволяет выявить “узкие” места в приложении, связанные с производительностью, а также обнаружить опасные утечки памяти.

Случайное тестирование (fuzzy testing, “monkey” testing) – приложение должно корректно реагировать на возникновение случайных и непредсказуемых событий. Мобильные устройства чаще других попадают в условия, в которых получают хаотичную бесполезную информацию (например, незаблокированный девайс в кармане), потому приложение должно адекватно реагировать на подобные потоки данных.

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

Лабораторное тестирование – имитация реальных условий качества связи и окружающей среды. Обычно неочевидно, как поведёт себя приложение, например, при нестабильном сигнале Wi-Fi или с нулевым балансом на счету в сети 3G. Данный вид тестирования позволяет проверить подобные случаи.

Аттестационное тестирование используется для подтверждения соответствия приложения стандартам, лицензионным соглашениям и условиям использования:

Android

• Установочный файл приложения (.apk) должен быть согласован с Program Policies .
• В случае публикации обновлённой сборки желательно придерживаться порядка управления версиями (например, принятого порядка нумерации версий).
• Приложение не должно противоречить документу UIG .

Так же для отдельных магазинов приложений (Amazon App Store, Samsung Apps, Yandex.Store и подобных) могут существовать свои собственные требования и гайдлайны.

---