Разработка мобильного приложения

Содержание:

Введение

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

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

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

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

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

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

Объектом исследования в данной работе является сфера мобильных приложений.

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

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

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

– рассмотреть этапы разработки мобильного приложения;

– рассмотреть этапы тестирования мобильного приложения;

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

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

Использование методов позволило обеспечить достоверность и обоснованность выводов.

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

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

Основное внимание в данной работе уделялось следующим литературным источникам:

1. Гаврилов Л. П.  Инновационные технологии в коммерции и бизнесе: учебник для бакалавров / Л. П. Гаврилов. – Москва: Издательство Юрайт, 2019. – 372 с. – (Бакалавр и магистр. Академический курс). 
2. Милехина О. В. Информационные системы: теоретические предпосылки к построению: учеб пособие / О. В. Милехина, Е. Я. Захарова, В. А. Титова. – 2-е изд-е. – Новосибирск: Изд-во НГТУ, 2014. - 283 с.
3. Семенчук В. Мобильное приложение как инструмент бизнеса: Справочное пособие / Семенчук В. – М.:АЛЬПИНА, 2017. – 240 с.
4. Соколова В. В. Разработка мобильных приложений: Учебное пособие / Соколова В.В. – Томск: Изд-во Томского политех. университета, 2014. – 176 с.
5. Соколова В. В.  Вычислительная техника и информационные технологии. Разработка мобильных приложений: учебное пособие для вузов / В. В. Соколова. – Москва: Издательство Юрайт, 2020. – 175 с. – (Высшее образование). 

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

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

1 Разработка мобильного приложения

1.1 Формирование требований

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

Необходимо провести прототипирование приложения. Прототип – это макет будущего приложения. Прототип может быть статичный или интерактивный – с кнопками действий и переходами [2]. Во многом благодаря процессу прототипирования становится возможным определить необходимость тех или иных функций приложения, удобство расположения тех или иных элементов [8].

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

Содержание ТЗ:

1. Общие сведения.

– полное наименование системы и ее условное обозначение;

– шифр темы или шифр (номер) договора;

– наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

– перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

– плановые сроки начала и окончания работы по созданию системы;

– сведения об источниках и порядке финансирования работ;

– порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы [11].

2. Назначение и цели создания (развития) системы.

– назначение системы;

– цели создания системы.

3. Характеристики объекта автоматизации

– краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

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

4. Требования к системе.

– требования к системе в целом;

– требования к функциям (задачам), выполняемым системой;

– требования к видам обеспечения.

5. Состав и содержание работ по созданию (развитию) системы.

Должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ [20].

6. Порядок контроля и приемки системы.

– виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

– общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации [4];

– статус приемочной комиссии (государственная, межведомственная, ведомственная).

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

– приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) [3];

– изменения, которые необходимо осуществить в объекте разработки;

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

8. Требования к документированию [9].

– согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях;

– требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

– при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов [23].

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

1.2 Выбор платформы и IDE

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

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

В связи с тем, что данный процесс является одним из основных, рассмотрим более подробно анализ рынка платформ и IDE.

На данный момент ситуация на IT-рынка такова, что наибольшее распространение имеет платформа Android, а соответственно и большее количество разработчиков; на втором месте идет платформа iOS, далее с большим отрывом Windows Phone и остальные платформы, которые на данный момент практически не используются [5]. Стоит отметить, что Android и iOS делят мобильный рынок практически поровну, с перевесом примерно в 10% в пользу Android.

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

IDE представляет собой интегрированную среду разработки, состоящую из системы программных средств, позволяющих осуществлять разработку программного обеспечения [8].

На рисунке 1 показаны основные средства, предоставляемые IDE.

Рисунок 1 – Основные средства, предоставляемые IDE

Кроме того в разных IDE могут предоставляться дополнительные инструменты, облегчающие процесс разработки, к примеру, для конструирования GUI [4].

1. Среды разработки для Android.

Intellij IDEA представляет собой среду разработки от компании JetBrains. В качестве инструмента сборки приложений используется Ant.

На сайте разработчика имеется документация по работе в системе [15]. Также отметим, что анализ отзывов многих пользователей данной среды разработки позволил сделать вывод, что среда успешно справляется с поставленными перед разработчиками задачами [21]. Однако отмечается ряд недостатков:

– низкая производительность;

– процесс компиляции, перекомпиляции, тестирования выполняется достаточно долго.

На рисунке 2 представлен интерфейс Intellij IDEA.

Рисунок 2 – Интерфейс Intellij IDEA

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

Android Studio представляет собой интегрированную среду разработки. В основе данной среды лежит IntelliJ IDEA. Несмотря на сходство интерфейсов, данные среды отличает инструмент сборки приложений, в случае с Android Studio используется встроенный инструмент Gradle [4].

Android Studio поддерживает различные виды сборок и генерацию нескольких .apk файлов, а так же разработку приложений для Android Wear и Android TV. Важной особенностью данной IDE является наличие статического анализатора кода, благодаря которому становится возможным найти уязвимые места в производительности, а также проблемы в случае несовместимости версий [2].

На рисунке 3 представлен интерфейс Android Studio.

Рисунок 3 – Интерфейс Android Studio

Данная среда разработки имеет хорошую документацию, множество примеров в сети Интернет [17]. Кроме того, многие пользователи отмечают высочайшую скорость работы, что, безусловно, положительным образом сказывается во время разработки.

Eclipse является свободной интегрированной средой разработки модульных кроссплатформенных приложений. Разработчик системы – Eclipse Foundation [7]. Многие пользователи данной IDE отмечают сложность процесса установки, необходимость дополнительных настроек системы, таким образом, отсутствие возможности «установить и приступить к разработке».

Система имеет множество расширений, что делает работу с системой еще более комфортной. Благодаря наличию в IDE системы контроля версий, работать над проектами можно группами [3]. В системе имеется поддержка связи между IDE и системой управления задачами (ошибками). Кроме того основная поставка IDE имеет поддержку трекера ошибок Bugzilla.

Многие пользователи системы отдают свое предпочтение в пользу Eclipse в силу ее бесплатности и высокого качества.

На рисунке 4 представлен интерфейс Eclipse. Многие пользователи отмечают, что интерфейс системы лишен самого главного – простоты и удобства, что причиняет ряд неудобств при работе в системе [18].

Рисунок 4 – Интерфейс Eclipse

Вывод: Еще несколько лет назад Eclipse была практически монополистом для разработки под платформу Android. На данный момент Eclipse практически не поддерживается Google, связано это с появлением на рынке Android Studio, которая завлекла практически весь рынок.

Стоит подчеркнуть, что Android Studio разрабатывается при поддержке разработчиков платформы Android, что, бесспорно, является существенным преимуществом [14].

Несмотря на то, что Android Studio имеет столько преимуществ, многие пользователи используют Intellij IDEA, отмечая при этом, что совершенно не могут работать в Android Studio, несмотря на их схожий интерфейс [1]. В свою очередь и у Eclipse имеются свои поклонники, по большей части ими являются те, кто начинал разработку именно с данной платформы и уже смирился со всеми ее недостатками и по достоинству ценит ее преимущества.

2. Среды разработки для iOS.

Если для системы Android на рынке имеется несколько IDE, которые ведут постоянную конкурентную борьбу за пользователей, то для платформы iOS следует рассмотреть только одну IDE – XCode. При этом данное решение не означает, что отсутствуют другие IDE для разработки под платформу iOS, это означает, что у XCode нет прямых конкурентов [19].

На рисунке 5 представлен интерфейс XCode.

Рисунок 5 – Интерфейс XCode

XCode обеспечивает инструменты для управления всем потоком операций разработки – от создания приложения, к тестированию, оптимизации и представлению его к App Store.

Важной особенность IDE является то, что она тесно интегрирована с фреймворком Cocoa. Данное решение позволяет получить производительную и простую в использовании среду разработки [3]. При этом стоит отметить, что данной фреймворк используют и при разработке самой операционной системы Apple Mac OS X. Данный набор инструментов включает: Xcode IDE; Interface Builder; инструменты для анализа поведения и производительности; десятки дополнительных инструментов [16].

Таким образом, обзор Xcode IDE позволил сделать вывод, что среда предоставляет разработчикам мощнейшие инструменты для работы, отсюда становится очевидна причина, почему данная среда является практически монополистом рынка IDE мобильной разработки под платформу iOS.

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

IOS разработка на сегодняшний день активно набирает обороты в связи с ростом пользователей Apple-устройств. Для этого XCode является отличным инструментом, предоставляющим широкий спектр возможностей.

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

1.3 Кодирование

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

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

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

1.4 Проектирование интерфейса

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

В момент проектирования интерфейса следует обращать внимание на два ключевых момента

1) восприятие человеком цвета;

2) принципы построения эффективного дизайна.

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

Восприятие зависит от нескольких факторов:

– восприятие приложения целиком;

– психологическое и физиологическое состояние пользователя;

– форма элементов дизайна;

– как выглядят мелкие детали;

– как читается информация [6].

Следует не забывать и о том, на какую аудиторию направлено мобильное приложение. Для детей цветовая схема должна содержать яркие, теплые и красочные цвета, для людей среднего возраста – цвета средней насыщенности, более холодные и смешанные, для людей старшего возраста – пастельные, мягкие тона [11].

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

1. Цвета должны соответствовать тематике приложения и гармонировать между собой (гармонирующие цвета – цвета, которые находятся рядом друг с другом на цветовом круге, к примеру, розовый с красным, желтый с оранжевым, и т.д.);

2. Цветовой тон и насыщенность должны соответствовать фирменному стилю;

3. Количество цветов должно быть около трех (конечно, если это не игровое приложение);

4. Подбирать цвет нужно с учетом возрастной категории посетителей [16].

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

Рассмотрим основные принципы построения эффективного дизайна.

1. Принцип «Золотого сечения». Основная мысль принципа заключается в том, что при разметке блоков еще на этапе разработки необходимо соблюдать пропорцию, равную приблизительно 1.618. При нарушении пропорции пользователь будет испытывать внутренний диском-форт. Внутренне человек настроен именно на такое соотношение [17].

2. Закон Хика. «Каждый дополнительный этап выбора увеличивает время, необходимое для принятия решения».

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

3. Закон Фиттса. Закон предусматривает, что на принятие решения требуется время. Чем труднее совершить это действие, тем больше времени.

Чем сложнее путь для получения результата, тем больше требуется времени, тем больше времени у пользователя на то, чтобы передумать использовать данное приложение в дальнейшем [3].

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

5. Законы дизайна гештальта. Для дизайна законы гештальт-теории играют немаловажную роль [11].

Выделим для рассмотрения четыре принципа.

5.1. Закон близости. «Объекты, расположенные ближе друг к другу, воспринимаются как взаимосвязанные в отличие от тех, что расположены дальше друг от друга».

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

5.2. Закон подобия. Объекты, имеющие общие внешние параметры (цвет, форма, размер и т. п.) воспринимаются как единое целое [8].

5.3. Закон замкнутости. «При взгляде на сложно расположенные элементы мы стремимся увидеть в них простую узнаваемую форму».

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

5.4. Закон непрерывности. Для человеческого восприятия характерна тенденция воспринимать линию, как некую «связующую нить» [14]. Таким образом, «если два элемента размещены вдалеке друг от друга, но соединены линиями, пусть даже пересекающимися, связь между ними останется неразрывной» [18].

2 Тестирование мобильного приложения

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

Другое название теста – тестовый вариант. Полную проверку приложения гарантирует исчерпывающее тестирование. Оно требует проверить все наборы исходных данных, все варианты их обработки и включает большое количество тестовых вариантов [3]. Исчерпывающее тестирование во многих случаях затруднительно, поскольку срабатывают ресурсные ограничения (прежде всего, ограничения по времени) [7]. Хорошим считают тестовый вариант с высокой вероятностью обнаружения еще не раскрытой ошибки. Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку.

Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

Тестирование обеспечивает: обнаружение ошибок; демонстрацию соответствия функций приложения его назначению; демонстрацию реализации требований к характеристикам приложения; отображение надежности как индикатора качества мобильного приложения [12].

Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов).

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

Рисунок 6 – Виды тестирования

2.1 Тестирование установки

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

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

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

Тестирование совместимости позволяет убедиться, что приложение может успешно перемещаться из одной среды в другую [18]. Другими словами, это позволяет определить, готов ли продукт к работе на разных платформах с различными конфигурациями оборудования и/или программного обеспечения. Это особенно актуально для кроссплатформенных приложений, разработанных одновременно под Android и iOS. Перечислим, что может спровоцировать проблемы совместимости:

– недостаток оперативной памяти;

– недостаток дискового пространства;

– определенные типы процессора и операционной системы;

– совместимость между различными типами операционных систем [13].

2.3 Стрессовое тестирование

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

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

Внутренние факторы: нехватка оперативной памяти или места на диске, низкий заряд аккумулятора, отключение каких-либо услуг (например, GPS) и т. д.

Стоит отметить, что полностью исчерпать тестовые варианты в данном случае не представляется возможным, потому что никогда не известно как будет себя вести пользователь во время использования мобильного приложения [22]. Можно лишь протестировать наиболее вероятные случаи использования.

2.4 Нагрузочное тестирование

Нагрузочное тестирование позволяет определить имеет ли приложение какие-либо уязвимые места. Например, утечки памяти или проблемы с производительностью. При нагрузочном тестировании мобильных приложений предполагается, что программа будет запускаться на устройстве с низким объемом памяти [17].

2.5 Функциональное и юзабилити тестирование

Рассмотрим информационные потоки процесса тестирования (рисунок 7).

Рисунок 7 – Информационные потоки тестирования

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

Выполняются тесты, все полученные результаты оцениваются. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами. Когда обнаруживается несовпадение, фиксируется ошибка – начинается отладка. Процесс отладки непредсказуем по времени. На поиск места дефекта и исправление может потребоваться час, день, месяц [19]. Неопределенность в отладке приводит к большим трудностям в планировании действий [14]. После сбора и оценивания результатов тестирования начинается отображение качества и надежности разработанного приложения.

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

В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы, и что в приложении нет скрытых ошибок [14]. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).

Существуют два принципа тестирования:

1. Функциональное тестирование (тестирование «черного ящика»).

Схема тестирования «черного ящика» представлена на рисунке 8.

Рисунок 8 – Тестирование «черного ящика»

Известны: функции программы.

Исследуется: работа каждой функции на всей области определения. Основное место приложения тестов «черного ящика» – интерфейс приложения.

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

При тестировании «черного ящика» рассматриваются системные характеристики приложения, игнорируется их внутренняя логическая структура. Исчерпывающее тестирование, как правило, невозможно [8]. Тестирование «черного ящика» не реагирует на многие особенности ошибок, допущенные в программном коде.

Для проведения тестирования следует:

1. убедиться в том, что кнопки имеют нормальный размер и подходят для крупных пальцев [11];
2. поместить кнопки в одной области экрана, чтобы не вызвать замешательства у пользователей;
3. убедиться в том, что значки и картинки смотрятся естественно в среде приложения;
4. убедиться в том, что цвет кнопок, выполняющих одну и ту же функцию, совпадает;
5. убедиться в правильной работе системы уменьшения и увеличения масштаба просмотра;
6. обеспечить минимальный ввод данных с клавиатуры;
7. убедиться в наличии возможности возврата или отмены действия в случае нажатия не на ту кнопку;
8. убедиться в том, что контекстуальные меню не перегружены, так как они предполагают быстрое использование;
9. убедиться в том, что текст прост, ясен и виден пользователю;
10. убедиться в том, что короткие предложения и абзацы возможно прочитать;
11. найти оптимальный размер шрифта [13];
12. убедиться в том, что в случае загрузки пользователем больших объемов информации приложение предупреждает о возможных сбоях в его работе из-за этого;
13. убедиться в том, что завершить работу приложения можно из любого состояния и что оно возобновляет работу в этом же состоянии;
14. проверить, что все строки отображаются на нужном языке, если в приложении есть опция перевода;
15. убедиться в том, что компоненты приложения синхронизируются с действиями пользователя [2];
16. обеспечить пользователя руководством, которое бы помогло ему понять работу приложения и эффективно им пользоваться;

2. Структурное тестирование (тестирование «белого ящика»).

Схема тестирования «белого ящика» представлена на рисунке 9.

Рисунок 9 – Тестирование «белого ящика»

Известна: внутренняя структура приложения (код).

Исследуются: внутренние элементы приложения и связи между ними.

Объектом тестирования здесь является не внешнее, а внутреннее поведение приложения. Проверяется корректность построения всех элементов программного кода и правильность их взаимодействия друг с другом [16]. Обычно анализируются управляющие связи элементов, реже – информационные связи. Тестирование по принципу «белого ящика» характеризуется степенью, в какой тесты выполняют или покрывают логику (исходный текст) программы [10]. Исчерпывающее тестирование также затруднительно.

Основные сценарии функциональных тестов:

1. проверить корректность работы обязательных полей;
2. убедиться, что обязательные поля отображаются на экране не так, как необязательные;
3. убедиться, что работа приложения во время запуска/выхода удовлетворяет основным требованиям;
4. убедиться, что приложение переходит в фоновый режим в случае входящего звонка.
5. проверить, может ли телефон хранить, принимать и отправлять SMS-сообщения во время работы приложения [7];
6. убедиться, что устройство работает в многозадачном режиме, когда это необходимо;
7. проверить, как функционируют необходимые опции для работы с социальными сетями – Поделиться, Публикация, Навигация;
8. убедиться, что приложение поддерживает платежные операции через системы оплаты Visa, Mastercard, Paypal и др.;
9. проверить адекватность работы сценариев прокрутки страницы;
10. проверить, присутствует ли надлежащая навигация между важными модулями приложения [4];
11. убедиться, что количество ошибок округления минимально;
12. проверить наличие сообщений об ошибках, например, сообщения «Ошибка сети. Пожалуйста, попробуйте позже» в случае некорректной работы сети;
13. убедиться, что установленное приложение не препятствует нормальной работе других приложений и не съедает их память;
14. проверить, способно ли приложение вернуться в то состояние, в котором оно находилось перед приостановкой (например, жесткая перезагрузка или системный сбой);
15. установка приложения должна проходить без значительных ошибок при условии, что устройство соответствует системным требованиям;
16. убедиться, что автоматический запуск приложения работает корректно [17];
17. проверить, как приложение работает на всех устройствах поколений 2G, 3G и 4G;
18. выполнить регрессивное тестирование для выявления новых программных ошибок в существующих и уже модифицированных областях системы;
19. убедиться, что существует доступное руководство пользователя [3].

3 Ввод в эксплуатацию

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

На рисунках 10-12 рассматриваются данные этапы более подробно.

Рисунок 10 – Проведение предварительных испытаний [3]

Рисунок 11 – Проведение опытной эксплуатации [7, 15]

Рисунок 12 – Проведение приемочных испытаний [19]

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

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

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

Наиболее короткий – последний этап [19]. Как правило, к данному этапу приложение полностью готово к эксплуатации, все недочеты устранены, дополнительные требования, появившиеся на этапе эксплуатации, реализованы.

Заключение

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

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

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

В работе были выполнены все поставленные во введении задачи, что привело к достижению поставленной цели.

Список использованной литературы

1. Аксенов К. В. Обзор современных средств для разработки мобильных приложений // Новые информационные технологии в автоматизированных системах. 2014. №17. URL: https://cyberleninka.ru/article/n/obzor-sovremennyh-sredstv-dlya-razrabotki-mobilnyh-prilozheniy (дата обращения: 22.04.2020).
2. Васильева К. Н., Хусаинова Г. Я. Обзор программных средств для разработки мобильных приложений // Colloquium-journal. 2020. №2 (54). URL: https://cyberleninka.ru/article/n/obzor-programmnyh-sredstv-dlya-razrabotki-mobilnyh-prilozheniy (дата обращения: 22.04.2020).
3. Васильева К. Н., Хусаинова Г. Я. Обзор программных средств для разработки мобильных приложений // Colloquium-journal. 2020. №2 (54). URL: https://cyberleninka.ru/article/n/obzor-programmnyh-sredstv-dlya-razrabotki-mobilnyh-prilozheniy (дата обращения: 28.04.2020).
4. Верескун Д.М. Разработка мобильных приложений для бизнеса: учебное пособие/ Верескун Д.М. – Саратов: Саратовский государственный технический университет имени Ю.А. Гагарина, ЭБС АСВ, 2012. – 51 c.
5. Гаврилов Л. П.  Инновационные технологии в коммерции и бизнесе: учебник для бакалавров / Л. П. Гаврилов. – Москва: Издательство Юрайт, 2019. – 372 с. – (Бакалавр и магистр. Академический курс). 
6. Гиматдинов Р. C., Тенденции развития сферы разработки мобильных приложений // Скиф. 2019. №6 (34). URL: https://cyberleninka.ru/article/n/tendentsii-razvitiya-sfery-razrabotki-mobilnyh-prilozheniy (дата обращения: 22.04.2020).
7. Допира Р. И., Попова Н. В. Разработка приложения в среде AndroidStudio // Наука, техника и образование. 2017. №3 (33). URL: https://cyberleninka.ru/article/n/razrabotka-prilozheniya-v-srede-androidstudio (дата обращения: 20.04.2020).
8. Жуковская А.Н., Заушицина А.С. Особенности разработки кроссплатформенных мобильных приложений // Решетневские чтения. 2017. №21-2. URL: https://cyberleninka.ru/article/n/osobennosti-razrabotki-krossplatformennyh-mobilnyh-prilozheniy (дата обращения: 27.04.2020).
9. Ким В. Ю. Особенности разработки дизайна пользовательского интерфейса для мобильного приложения // Новые информационные технологии в автоматизированных системах. 2015. №18. URL: https://cyberleninka.ru/article/n/osobennosti-razrabotki-dizayna-polzovatelskogo-interfeysa-dlya-mobilnogo-prilozheniya (дата обращения: 28.04.2020).
10. Майорова Е. С., Ошурков В. А., Цуприк Л. С. Современное состояние средств разработки мобильных приложений на платформах iOS, Android и Windows Phone // ПНиО. 2015. №4 (16). URL: https://cyberleninka.ru/article/n/sovremennoe-sostoyanie-sredstv-razrabotki-mobilnyh-prilozheniy-na-platformah-ios-android-i-windows-phone (дата обращения: 22.04.2020).
11. Милехина О. В. Информационные системы: теоретические предпосылки к построению: учеб пособие / О. В. Милехина, Е. Я. Захарова, В. А. Титова. – 2-е изд-е. – Новосибирск: Изд-во НГТУ, 2014. - 283 с.
12. Русанова И. В. Анализ платформ для разработки гибридного мобильного приложения для систем iOS и Android // Актуальные проблемы авиации и космонавтики. 2017. №13. URL: https://cyberleninka.ru/article/n/analiz-platform-dlya-razrabotki-gibridnogo-mobilnogo-prilozheniya-dlya-sistem-ios-i-android (дата обращения: 22.04.2020).
13. Свентицкий П. И., Иванова Н. А. Инструменты кроссплатформенной разработки мобильных приложений // Инновации в науке. 2014. №40. URL: https://cyberleninka.ru/article/n/instrumenty-krossplatformennoy-razrabotki-mobilnyh-prilozheniy (дата обращения: 28.04.2020).
14. Семенчук В. Мобильное приложение как инструмент бизнеса: Справочное пособие / Семенчук В. – М.:АЛЬПИНА, 2017. – 240 с.
15. Соколова В. В. Разработка мобильных приложений: Учебное пособие / Соколова В.В. – Томск: Изд-во Томского политех. университета, 2014. – 176 с.
16. Соколова В. В.  Вычислительная техника и информационные технологии. Разработка мобильных приложений: учебное пособие для вузов / В. В. Соколова. – Москва: Издательство Юрайт, 2020. – 175 с. – (Высшее образование). 
17. Ургенчев А. Р., Байбактина А. Т. Анализ современных средств для разработки мобильных приложений под ОС Android // Научный журнал. 2017. №3 (16). URL: https://cyberleninka.ru/article/n/analiz-sovremennyh-sredstv-dlya-razrabotki-mobilnyh-prilozheniy-pod-os-android (дата обращения: 22.04.2020).
18. Ургенчев А. Р., Байбактина А. Т. Анализ современных средств для разработки мобильных приложений под ОС Android // Научный журнал. 2017. №3 (16). URL: https://cyberleninka.ru/article/n/analiz-sovremennyh-sredstv-dlya-razrabotki-mobilnyh-prilozheniy-pod-os-android (дата обращения: 27.04.2020).
19. Фадеев А. Ю., Волкова Е. А. Сравнительный анализ программного обеспечения для разработки мобильных приложений // Наука и перспективы. 2016. №3. URL: https://cyberleninka.ru/article/n/sravnitelnyy-analiz-programmnogo-obespecheniya-dlya-razrabotki-mobilnyh-prilozheniy (дата обращения: 22.04.2020).
20. Фадеев А.Ю., Волкова Е.А. Сравнительный анализ программного обеспечения для разработки мобильных приложений // Наука и перспективы. 2016. №3. URL: https://cyberleninka.ru/article/n/sravnitelnyy-analiz-programmnogo-obespecheniya-dlya-razrabotki-mobilnyh-prilozheniy (дата обращения: 20.04.2020).
21. Федотенко М.А. Разработка мобильных приложений. Первые шаги / М.А. Федотенко; под ред. В.В. Тарапаты. – Москва: Лаборатория знаний, 2019. – (Школа юного программиста).
22. Цыганенко В. Н. CALS/CASE-технологии проектирования информационных систем: конспект лекций. Изд-во ОмГТУ, 2007. - 86 с.
23. Чистов Д. В., Мельников П. П., Золотарюк А. В., Ничепорук Н. Б. Проектирование информационных систем: учебник и практикум для академического бакалавриата / Д. В. Чистов, П. П. Мельников, А. В. Золотарюк, Н. Б. Ничепорук; под общей редакцией Д. В. Чистова. – Москва: Издательство Юрайт, 2019. – 258 с. – (Высшее образование).