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

Анализ архитектуры и построение модели угроз и рисков Определение критериев защищенности

 Поиск уязвимостей в исходном коде

 Fuzz тестирование

 Тестирование на проникновение

 Тестирование, основанное на рисках

 Проведение нагрузочного тестирования

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

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

Основные задачи системного тестирования сводятся к алгоритмизации и методическому описанию сценариев тестирования (см. шаблон метода сценариев):

Определение подхода к составлению тестовых сценариев

 Создание плана и методики испытаний

 Подготовка тестовых данных

 Проведение тестирования

 Интеграционное тестирование

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

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

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

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

 Бизнес-требования

 Функциональные требования

 Техническое задание

 Руководства пользователей

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

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

Рассмотрим основные виды тестирования.

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

 Оценка возможностей системы и определение максимальной производительности.

 Выявление ошибок (например, утечка памяти, некорректные настройки или распределение ресурсов). Предупреждение отказов системы в промышленной эксплуатации.

 Поиск оптимального комплекса технических средств.

Проводится анализ целей и статистики эксплуатации системы. Определяются бизнес-операции, имеющие значение с точки зрения 10 нагрузки на систему. Создается и согласуется документ «Методика нагрузочного тестирования», который включает: стратегию тестирования, список и описание тестов, критерии успешного завершения, описание средств мониторинга и инструментов нагрузочного тестирования. Осуществляется подготовка тестовых данных, настраивается мониторинг, наполняется база данных. Выполняется запись и отладка скриптов нагрузочного тестирования и реализация сценариев нагрузочного тестирования. С помощью разработанной системы нагрузочного тестирования выполняется тестирование приложений. В рамках нагрузочных испытаний собирается различная статистическая информация, с помощью которой выполняется анализ производительности. 3. После проведения нагрузочного тестирования заказчику предоставляется отчет, который описывает результаты тестирования, отступления от методики (если имеются), список ошибок, предложения по оптимизации работы системы, общие замечания. Инженеры-тестировщики при выполнении нагрузочного тестирования чаще всего используют продукты следующих вендоров отрасли: HP LoadRunner, Apache JMeter, IBM Performance Tester, MS Visual Studio Ultimate. Направления нагрузочного тестирования Тестирование производительности Тестирование производительности позволяет определить максимальную интенсивность операций, при которой система удовлетворяет требованиям ко времени отклика. Тестирование производительности рекомендуется проводить для новой версии ПО, планируемого к внедрению. Результат проведения тестирования выявляет и предотвращает отказы системы перед внедрением в промышленную эксплуатацию, определяет максимальное количество одновременно работающих пользователей в системе и максимальное количество одновременно выполняемых операций без потери качества обслуживания.

В рамках тестирования производительности собирается статистика использования системы, на основе которой составляется профиль нагрузки. После этого вычисляется начальная точка и размер шага для увеличения интенсивности выполнения операций. В ходе выполнения тестирования определяется максимальная производительность системы (см. шаблон тестирования производительности): наибольшая интенсивность выполнения операций с требуемым качеством обслуживания (SLA); пиковая производительность системы, при которой происходит ухудшение показателей качества обслуживания операций (время выполнения, отказы).

Объемное тестирование.

Данный вид тестирования позволяет проверить использование системных ресурсов при увеличении объема данных и принять проактивные меры для предотвращения отказа системы в будущем. Объемное тестирование подходит не только для систем, планируемых к внедрению в опытно-промышленную эксплуатацию, но и на стадии проектирования. Объемное тестирование позволяет определить глубину хранения данных, при которой не произойдет деградации производительности системы, подобрать оптимальный комплекс технических средств, выявить лучшее архитектурное решение для системы, находящейся на этапе проектирования. Главной задачей объемного тестирования является оценка производительности системы при увеличении потока данных. В ходе тестирования эмулируется увеличение интенсивности операций системы с одновременным увеличением объемов базы данных. В процессе тестирования измеряется общая производительность системы: количество операций за определенный период времени, время отклика системы и количество пользователей, одновременно работающих в системе. 12 Тестирование стабильности Тестирование стабильности предназначено для оценки возможности системы работать длительное время под нагрузкой. Позволяет выявить утечки памяти или некорректные настройки ПО. Данный вид работ рекомендуется проводить как для новых систем, так и для новых версий уже эксплуатируемого ПО. Тестирование стабильности позволяет предупредить сбои системы и ухудшение скорости и качества обработки данных, проверить возможность стабильной работы системы, находящейся под длительной нагрузкой, определить характеристики системы, которые подлежат отслеживанию в ходе опытно-промышленной эксплуатации, выявить недостаток аппаратных и системных ресурсов до внедрения в опытно- промышленную эксплуатацию. В ходе тестирования стабильности на целевую систему в течение не менее 24 часов подается средний уровень нагрузки, 70-80% от максимального уровня.

Стресс-тестирование.

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

1. Если велика стоимость отказа системы в экстремальных ситуациях. 2. Если есть возможность резкого увеличения нагрузки на систему в экстремальных ситуациях. Выявляются узкие места в отдельных компонентах системы, из-за которых возможно снижение производительности системы в стрессовых 13 условиях. Определяются показатели нагрузки системы, при которых система отвечает требованиям к производительности, заявленным на этапе проектирования.

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

Подбор оборудования

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

Заключение

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

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

• От каждой новой платформы пользователь хочет увидеть богатое приложение. Рассуждение человека строится так: «У меня был плохой  Java-телефон и я все же мог использовать аську. Но когда купил новый более дорогой телефон, то зашел в Marketplace и не увидел там ICQ. Почему?». Пользователь же не знает, что вам пришлось создавать приложение с нуля, а новая платформа включает в себя новые девайсы, документацию и ресурсы.
• У более популярных платформ больше конкурентов. Увидеть эту закономерность можно на примере двух сторов: AppStore и Google Play. При наличии у вас идеи приложения, легко монетизируемого, или того, которое будут много скачивать, если вы введете ключевые слова в строке поиска, то увидите, что данное приложение уже есть. Получается, что чем платформа более популярная, тем больше конкурентов вы встретите. Поэтому очень внимательно следует изучить аналоги, анализировать статистику, а также пробовать понять, в каких сферах и параметрах вы можете превзойти конкурента.
• Очень важно знать, как именно пользователь осуществляет выбор приложения. Обычно вначале пользователь не имеет желания покупать приложение, он просто просматривает список существующих предложений. Возьмем для примера запрос «бесплатная музыка». В первую очередь на глаза человеку попадается иконка и несколько строк с описанием. Именно это увидит и оценит пользователь, на основании чего сделает выбор – покупать приложение или нет. Важно знать, что плохая иконка значительно уменьшает шансы на скачивание, поэтому необходимо позаботиться о достойной иконке.
• Если вы попадете в топ магазина приложений, то это очень хорошо, а если закрепитесь там – то успех вам обеспечен. Что это дает? Зайдя в чарт, при необходимости скачать какое-либо приложение, пользователь смотрит, какое именно из всех находится на первом месте по числу скачиваний. Так как считается, что самые популярные приложения – это самые лучшие и полезные.  Это, можно сказать, замкнутый круг, в который очень важно попасть. Когда приложение попадает в топ, то люди его видят и скачивают, не продолжая поиски далее. Из-за большого количества скачиваний это приложение продолжает оставаться на первом месте и его видят новые пользователи и так далее. Такая интеграция может продолжаться длительное время, поэтому направьте все свои силы и возможности для того, чтобы добиться скачиваний и рейтинга на первых порах. Вы можете просить друзей, родных, близких, соседей и знакомых скачать ваше приложение и поставить ему высокую оценку. Чем больше пятерок будет поставлено вашему приложению, тем ближе оно будет подбираться к топу. Необходимо также сообщить о том, что существует масса решений для попадания в топ на рынке, то это принесет недостаточное количество целевой аудитории. Хотя экспериментировать можно со всем.
• Необходимо помнить, что время публикации может занимать даже несколько недель. К примеру, вы создали и протестировали приложение, позвонили всем блоггерам, сообщили в СМИ о том, что у вас новое приложение, и вы предлагаете прийти на пресс-конференцию. Прямо сегодня вы его отправили в AppStore, но вы должны подождать неделю (для России). А вот в Google Play публикация сможет занять всего лишь пару часов. Поэтому это настоящий рай для оперативных обновлений.
• В сторе нет возможности для общения с пользователями. Допустим, пользователь написал, что у него в аське не идут сообщения. Он при этом выражает весьма красочно свое недовольство, но при этом недостаточно информативно. Мы не имеем возможности связаться с ним, чтобы узнать о его проблеме в подробностях. Все, что в наших силах, это лишь возможность посмотреть в мониторинге, ходят ли сообщения у нас. Существует вероятность, что он заблочен антиспамом. Но на сегодняшний день некоторые сторы имеют админки, где есть возможность задать вопросы пользователям, а также узнать их контактные данные. Можно даже посмотреть из каких стран идет скачивание приложения. Но пока что ситуация не очень улучшилась. Интересно знать, что Google Play добавляет такую возможность для некоторых разработчиков. У нас такая возможность также доступна.
• Фрагментация операционной системы. При разработке приложения под Android необходимо принимать в учет фрагментацию, а также наличие огромного количества различных устройств. В свою очередь это не может не отразиться на времени разработки, на длительности проектирования, создания дизайна, а также особенно на этапе тестирования приложения. То есть увеличивается время всех этапов.
• Время на тестирование. Приложение может быть протестировано несколькими методами. К примеру, можно нанять специальных тестеров в свой штат с тест-планами и тест-кейсами. Они все это обязательно проходят. Но стоит также помнить и о сервисах для тестирования, где вы будете платить лишь за найденные баги. То есть после того, как вы выложите приложение, оно будет протестировано, например, 20 тысячами пользователей, но такой подход имеет как плюсы, так и минусы, о которых также нельзя забывать.
• При помощи кадров в мобильной индустрии можно решить все. Даже крупные компании, такие как Яндекс, Google  и Mail.Ru Group порой не могут найти достаточно хороших мобильных разработчиков. Исходя из этого, мы работаем со стажерами, ведь порой значительно проще взять умного студента и самостоятельно его обучить всему необходимому.