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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 31.03.2023

Просмотров: 81

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

2. Практическое и работа с VCS

2.1 мобильных приложений

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

Мобильное тестирование процесс: различных разрешений , аппаратные отличия, версий операционных , разные подключения к интернету, обрывы связи, и т.п. В с этим, хотелось , что у нас в отделе работает 8 человек (0,5 на программиста), за его развитием и следит выделенный -лид.

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

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

анализирует требования на и противоречивость. В проекте исходные содержат противоречивую . Мы их решаем еще до начала . Так же в каждом требования неполны, что сложность в работе: не макетов второстепенных , ограничения на х ввода, отображения , поставленные кнопки не , и т.д. (Приложение 1). Неочевидны на макетах : анимации, кеширование и содержимого экранов, в нестандартных ситуациях [14].

требований с менеджером проекта, и дизайнерами.

После 2-3 , вся команда гораздо понимает , вспоминает забытый , фиксирует решения по вопросам.

В основном на этапе basecamp [8].

Когда стали полны и , тестировщик составляет -тесты и тесты, покрывающие данные.

Тесты на общие и специфические для платформ.

Для и прогона тестов мы TFS. (Приложение 2).

Например, для Avocado на этом этапе написано 335 . 

Первый шаг тестирования . Проект уходит в . (Приложение 3).

Если проекта галочку «для », тестировщикам, уходит о новой сборке для . Ее номер на мониторе в кабинете .

Красным отображаются выпущенные за последние , их нужно активнее, чем белые [20].

Без « монитора» (работает на ) часто тестировали сборки . А новая сборка с багами попадала . Теперь перед тестового достаточно взглянуть на , путаница разрешилась.


сборок программы быстрое и .

2.3 Быстрое тестирование

тестирование проводится завершения итерации , если не пойдет в релиз.

Для проводятся smoke-, чтобы понять ли смысл сборку.

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

Некорректно выполненные переоткрываются. Баги заносятся в TFS. К не UI обязательно логи со смартфона. К UI скриншоты с пометками что не так [2]. ( 5).

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

Для андроид приложений monkey тесты.

adb shell monkey -p .droid --throttle 50 -- 0 --pct-ap

0 -v 5000

По окончании ставится отметка « багов пройдено» в -сервере [13]. ( 3).

Если в процессе не было найдено b, critical и major (Приложение 7), то отметка «можно заказчику». Ни один не отсылается заказчику без отдела . (По согласованию с заказчиком высылаются билды с багами). Критичность определяется по . (Приложение 5). После тестирования M получает письмо-отчет. (Приложение 6).

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

тестирование проводится релизом.

Включает в себя быстрое , регрессионное , monkey-тестирование на 100 и тестирование обновлений.

тестирование прогон тест-кейсов по проекту.

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

Очень важный шаг — обновлений.

все приложения хранят локально (даже это кука логина) и удостовериться, что обновления приложения все пользователя сохранятся.

скачивает билд из , создает данные (логин, , транзакции учета ), обновляет приложение на сборку и , что все на месте [19].

Затем smoke-тест.

повторяется на 2-3 устройствах.

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

Релизный -тест мы проводим на 10 IOS и 80 устройствах при помощи Appthwack.

В конце тестирования, кроме , вручную составляется отчет. (Приложение 8).

уходит в только при 100% всех тест-кейсов.

2.5 внешних сервисов [10]

интеграцию с Analytics (URL: https://www.google.com/analytics), (URL: https://y.flurry.com) или системой заказчика непросто. , что в релиз сборки с нерабочим Analytics и никто не на это внимания.

Поэтому в порядке для сервисов создается аккаунт, и он проверяется при тестировании. Кроме , отправка фиксируется в логах, проверяются тестировщиками [11].


2.6 времени

Учет тестировщиков п в отдельном TFS проекте. На тест-кейсов, прогон , написание отчетов по заводится задача и стандартными в ней отмечается затраченное .

2.7 Работа в VCS

Для начала нам тестовое для тестирования приложения. цикл тестирования длительный, а разработка быстро, то выделить еще и dev-окружение. VCS будет отражать окружения.

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

Как бы мы не сделать окружения , конфигурационные файлы отличаться: тестовые и аккаунты, , ID, внешние веб-сервисы и .NET предлагает отличное поддержание конфигураций в виде: конфигов. «Из коробки» они только в веб-приложения. К трансформации достаточно добавить и в приложения.

Начинающие часто находятся в недоумении при трансформаций Web.config’а на машинах: в от App.config’ов они хранятся на приложения, а не в папке bin, при локальной сборке не происходит. применяются при публикации . Если нам действительно обойти это ограничение, создать Web.template.config и добавить на PostBuild приложения.

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

NET предоставляет 2 для версионирования

[assembly: AssemblyVersion(

[assembly: AssemblyFileVersion(

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

В ходе исследования использованы различные внедрения CI на основе для мобильных - Avocado (Приложение 11), выявлены следующие , протекающие с использованием CI. рассмотрены .

2.8 SSDT-проект

(URL: https://.microsoft.com/en-us/mt186501)

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

Минусы: сложность миграционных . Т.к. инкрементальные изменения сам проект, сохранность обеспечивается за счет и post--скриптов. Придется на наличие/отсутствие полей в БД или «» таблицу schema , уже реализованную в движках.

2.9 ECM7 Migrator


миграций с открытым м (URL: https://github.com/117/ecm7).

Плюсы: поддерживаются СУБД, если вас не устраивает, код открыт. поддерживается и новыми функциями. И, , самое важное, несколько ключей в одной данных. Это может очень полезно, ваше приложение и поддерживает в том или ином виде. плагин может свои миграции и при использовать БД
Минусы: нет особенностей Framework Migrations.

2.10 Framework Migrations

(: https://msdn.microsoft.com/en-us/library/591621 (v=vs.113).aspx)

: работает из коробки, создает миграции по Db-, понимает из консоли visual , миграции публикуются с стандартного Publish из Studio.

: зависит от Entity .

Нумерация Автоматизация приложения:

В 2012 система web-проектов была улучшена. В первую это касается профилей .Если мы ем приложение в azure, то можно просто с портала. В противном его нужно создать. (Приложение 9).

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

Выводы

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

Integration , которая направлена на качества тестирования, что всего благополучно на работе тестировщиков. Есть ряд и не очень приятных для работников, которые возникнуть.

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

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

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

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

СI позволило работать на качества тестирования, это всего сказывается на работе тестировщиков. Также отметить, что увеличивается тестирования, т.е. скорость без использования CI. При приложения Avocado происходил только полного багов приложения в текущей итерации, а после полной кода на сервере. Время и исправления багов от количества найденных , в данном этот процесс 32 часа. (Приложение 12). При CI, тестировщикам не нужно ждать публикации кода , это позволило работать с ним но. В конкретном случае это 15 часов.(13) Все это может свидетельствовать о том, что CI позволяет работать над приложением более и качественно.


ЗАКЛЮЧЕНИЕ

Доля мобильного интернета растет ежедневно [15]. Многие люди проводят по нескольку часов в день, играя в различные компьютерные игры, в особенности в то время, когда ничего другого сделать нельзя, например, по дороге на работу, учебу, в поезде и т.д. Регулярно выходят новые компьютерные игры для телефонов и других мобильных устройств. Скачивание мобильных приложений не требует долгого времени и специальных навыков, установка также проста и понятна. В рамках работы было разработано мобильное приложение для Android. Для достижения данной цели были решены следующие задачи: 1) осуществлена постановку задачи, выделены требования к приложению; 2) произведен обзор существующих решений для разделения чеков; 3) изучены современные средства разработки мобильных приложений для Android; 4) определены требования и спроектировано мобильное приложение; 5) реализовано и протестировано мобильное приложение. Все поставленные задачи были решены, цель достигнута. Разработанное приложение имеет перспективы дальнейшего развития. С учетом усложнения бизнес-процесса и ростом требований заказчика, возникает потребность в расширении функционала системы. Перспективы дальнейшего развития мобильного приложения могут быть следующими: 1) программа должна давать пользователю возможность сохранения новых позиций чека при ручном вводе; 2) программа должна выводить детализацию выбранных и невыбранных позиций чека; 3) программа должна проверять наличие скидки на отдельные позиции чека или на всю сумму чека; 4) программа должна применять скидку к товарам пользователя при ее наличии; 5) программа должна уметь экспортировать фото и имена пользователей из контактов устройства; 6) программа должна уметь рассылать распознанные позиции с помощью списка контактов устройства.

СПИСОК ЛИТЕРАТУРЫ

1. Android Studio Features. [Электронный ресурс] URL: https://developer.android.com/studio/features.html (дата обращения: 20.08.19).

2. Appery.io: Enterprise Mobile App Builder & MBaaS. [Электронный ресурс] URL: https://appery.io/ (дата обращения: 20.08.19).

3. Кулямин В. Компонентная архитектура среды для тестирования на основе моделей. Программирование. 2010. Т. 5.

4. Кулямин В. В. Тестирование на основе моделей, URL: http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture04.pdf. (дата обращения 05.04. 2016).

5. Fork of Tesseract Tools for Android. [Электронный ресурс] URL: https://github.com/rmtheis/tess-two/ (дата обращения: 20.08.19).

6. Салмре И. Конечный автомат для пользовательского интерфейса. Программирование мобильных устройств на платформе .NET Compact Framework. Москва, Санкт-Петербугр, Киев : Вильяме, 2006.