Выпускная квалификационная работа



Скачать 349.61 Kb.
Дата24.12.2017
Размер349.61 Kb.
ТипПрограмма

Федеральное государственное автономное образовательное учреждение
высшего образования


КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ

ВЫСШАЯ ШКОЛА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И
ИНФОРМАЦИОННЫХ СИСТЕМ

Направление подготовки: 09.03.03 Прикладная информатика



ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка методологии для тестирования и внедрения CI по мобильному приложению

Работа завершена:

«___»_____________2017 г.

Студент группы ______ ___________________А.А. Гнеденков

Работа допущена к защите:

Научный руководитель

Доцент, к.н.

«___»_____________2017 г. ___________________И.Н. Голицына

Директор Высшей школы ИТИС

«___»_____________2017 г. __________________ А.Ф. Хасьянов

Казань – 2017 г.
Содержание


Введение 3

1. тестирования обеспечения 4

1.1 Основы программного обеспечения для устройств 4

1.2 Классификация мобильных 7

1.3 Виды 10

1.4 интеграция (Continuous ) 14

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

2.8 SSDT-проект 22

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

2.9 ECM7 Migrator 22

Список использованных источников 27




Введение

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

ПО предполагает запуск продукта в определенных , записывая и анализируя результаты и ошибки.

Программа не для того, чтобы , что она работает, а скорее – тестирование с предположения, что в ней ошибки. Актуальность заключается в том, что предположение практически для программы, а затем уже их максимально возможное . Методология для тестирования и Continuous (далее CI) по мобильному позволит более сказать о практике программного в моделях тестирования.

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

Основные задачи :

1) Изучение материалов и анализ средств для тестирования приложений разных (android, IOS и т.д.).

2) теоретических знаний на в тестировании мобильных с помощью внедрения CI.

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

Во второй главе непосредственное практическое применение и работу с Version Control System (далее VCS).

Сюда следующие : тестирование мобильных , тестирование , быстрое и полное , тестирование сервисов, учет во время тестирования, и в работы в VCS и его особенностями.

1. тестирования обеспечения

1.1 Основы программного обеспечения для устройств


Многие , занимающиеся программного обеспечения, до 50% , выделенных на разработку , тратят на тестирование, что миллиарды по всему миру в . И все же, несмотря на громадные , знаний о сути явно не и большинство программных неприемлемо ненадежно после «основательного ».

О состоянии дел всего свидетельствует тот , что большинство людей, в области обработки , даже не правильно определить «тестирование», и это на самом главная причина .

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

основные моменты, на необходимо особое внимание при тестировании мобильных .

Размер экрана и -интерфейс.

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

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

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

проверять использование в так называемых "" жестов (например, , doubletap), если , то соответствующий жест использоваться по , а если над каким-то действие, соответствующее не предусмотрено, то жест не должен. , в случае поддержки части приложения, должен использоваться по , если же нет выделять какой-то , то doubletap не должен ее [1].

Ресурсы устройства.

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

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

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

разрешения экрана и ОС.

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

Необходимо возможность адаптации к портретной и альбомной устройства. [24]

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

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

Реакция на внешние прерывания.

проверить работу в условиях эксплуатации устройства, а для устройств характерны изменения состояния: и исходящие звонки, SMS, MMS; устройства; в режим ожидания (в том и с защитой паролем); ориентации устройства в ожидания; и включение сети, , авиарежима, GPS; потеря с сервером или прокси ( есть, но не проходят); отключение и SD-карты, дополнительных ; зарядка устройства; с акселерометром; с физической клавиатурой ( в списке поддерживаемых есть такие) [3].

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

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

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

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

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

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

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

тестирование. имитацию реальных качества связи и среды, позволяет как поведет приложение при нестабильном Wi-Fi или с нулевым на счету в сети 3G [2].

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

требования к , разработанным для мобильных , работающих под управлением .

Установочный файл (.apk) должен согласован с Program (http://play.google.com/about/developer-content-policy.html).

В случае обновленной сборки придерживаться управления версиями (, принятого порядка версий) [4].

Приложение не противоречить GUI (http://developer.android.com/design/index.html).

Для отдельных ов приложений (Amazon App (URL: https://www.amazon.com/-apps) Apps (URL: http://www..com/ru/apps/mobile), .Store (URL: https://.yandex.ru) и подобных) могут свои собственные и гайдлайны.



1.2 Классификация мобильных

Тесты существенно по задачам, которые с их решаются, и по используемой . Различие тестирования приводит, образом, к необходимости весьма разнообразные (виды) . Принято подразделять на виды по следующим [3]:

по объектам (элементам) , часто на виды тестов по критерию называют тестирования на уровни;

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

Тем не , основная классификация на виды производится в с традиционными качества, которые с их помощью [4].

Уровни :

Модульное тестирование ( или Unit-):

Входные требования — компонентов или модель “ уровня” системы ( Design или Low Design).

Объект — разработанные компоненты.

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



тестирование (Сборочное , integration или interface testing) [6]:

требования — Архитектура или модель “верхнего ” системы ( Design или High Design).

Объект — собранная из компонентов или подсистема.

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

Комплексное тестирование не на проверку каждого из компонентов, а на взаимодействия компонентов в с «Архитектурой системы».

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



тестирование ( testing):

Входные — системные спецификации ( Specification).

Объект — разработанная .

Определение: после , как система собрана из компонентов, она должна протестирована на “Системным спецификациям” – ли все функциональные и нефункциональные к разрабатываемой системе.

На уровне приложение или система ( или более приложений) .

Приемочное тестирование ( тестирование или testing):

Входные — требования (requirements).

тестирования — разработанная .

Определение: на уровне завершенное (система) тестируется , конечными пользователями или уполномоченными с определения соответствия “Требованиям Заказчика” и системы к внедрению. испытания процесс передачи от Разработчика Заказчику. В от особенностей продукта и от Заказчика они проводиться в различной . Например, в виде альфа- или [10].



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

Бета - тестирование, этапом программного обеспечения альфа-тестирования. Программное в стадии бета - также как betaware [27]. Бета - обычно начинается, программное обеспечение законченным продуктом, но , , содержит ряд известных или ошибок [27]. Программное в фазе бета - , как правило, гораздо больше , чем в законченном программном , а также вопросы / производительности и может привести к или потери данных. В внимания бета - является воздействия на пользователей, включая юзабилити-тестирование. Процесс бета - тестирования до продукт бета - версией, и как , это первый раз, когда обеспечение доступно за и организации, над ним. Бета - версия обеспечения часто полезно для демонстрации и просмотров в организации и для потенциальных . Некоторые разработчики эту версию в качестве просмотра, версии, прототипа, просмотра, или ранний [28]. Некоторые программные хранятся в постоянной бета - , где новые возможности и постоянно добавляют к обеспечению без создания фирмы «» выпуска .

Приемочное тестирование с системным тестированием, но со различием:

Системное проверяет, что система соответствует требованиям;

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

Операционное (Release Testing):

требования — Бизнес (Business Case или Model).

тестирования — Разработанная .

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

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

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

(Verification) - это процесс системы или её с целью определения ли результаты текущего разработки условиям, в начале этапа [21]. Т.е. выполняются ли цели, сроки, по разработке проекта, в начале фазы.

Валидация () - это определение соответствия, ПО ожиданиям и потребностям , требованиям к [21].

Основное разделение на виды по объектам , или, точнее, на уровни , было нами при определении модели. Уровни приведены выше. Для уровня могут использоваться виды тестирования, для из которых, в свою , могут различные типы испытаний [25].

1.3 Виды


Инсталляционное тестирование ( testing):

: в процессе инсталляционного проверяется корректность и деинсталляции программного в среде приближенной к эксплуатационной. правильности установки продукта должна обязательным проекта по тестированию продукта [5]

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

Дымовое тестирование ( testing):

: Первый прогон (после написания или внесения существенных ). Как правило, для определения, готова ли для проведения более тестирования.

Цель: проблем « на поверхности» – тестируется всего основная логика программы.

тестирование ( testing):

Определение: соответствия продукта требованиям и спецификациям.

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

Регрессионное (Regression testing):

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

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

тестирование (Integration ):

Определение: Проверка компонентов прикладной с целью корректности их совместного .

Цель: Выявление проблем в совместном компонент.

графического интерфейса (User Interface ):

Определение: Тестирование – экранов, и т.д. Большая часть ПО реализуется, как правило, пользовательский интерфейс.

: Обнаружение в интерфейсе и поиск в функциональности посредством .

Тестирование производительности ( testing):

: Проверка скорости системы (время , частота транзакций и зависящие от ) в имитационной и реальной .

Цель: Установить производительность программного .

Нагрузочное (Load testing):

: Это те же тесты производительности, при система подвергается нагрузкам; при цель этого – оценить способность правильно функционировать при превышении нагрузок при реальной (система имеет «запас прочности») [1].

: Убедиться в том, что работает соответственно рабочим нагрузочным (какой предел ).

Стресс (Stress testing):

: Является одним из тестирования на производительность. поведение при недостатке ресурсов ( пространства, обрывов и т.д.).

Цель: Проверка , что система реагирует на те или иные ситуации.

Конфигурационное (Configuration testing):

: Конфигурационное – тестирование работы на платформах. Различные аппаратной конфигурации, операционной и окружения.

Цель: работоспособность системы при конфигурациях.

Локализационное (Localization ):

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

Цель: Проверить, ли локализован продукт.

тестов на производится в соответствие с показателями качества, проверяются с их помощью. словами, тестирования на виды в зависимости от типа (функциональные, нефункциональные), с помощью [17].

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

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

Тестирование удобства (usability) ПО (нефункциональные ) производится с целью в том, что приложение для использования его конечным . Включает в себя на человеческий фактор, интерфейса и его , наличие и качество и контекстной помощи, и учебных материалов [22].

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


1.4 интеграция (Continuous )


Непрерывная интеграция (. Continuous Integration) — это разработки обеспечения, которая в выполнении частых сборок проекта для выявления и интеграционных проблем.

С точки зрения это , что в любой момент у вас должна «живая актуальная продукта», которую протестировать или продемонстрировать.

Для нужно:

  1. разработчики вносили код в VCS по крайней мере день

  2. Сборка происходила в режиме

  3. Выкладка (в том числе, обновление данных) происходила в режиме

  4. продукта происходило в режиме (насколько это )

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

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

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

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

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

1.5 Особе тестирования мобильных

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

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

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

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

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

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

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

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

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

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

Рассмотрим популярные платформы и их при тестировании:

Android:


  • файл (.apk) должен быть с Program Policies .

  • В публикации обновлённой желательно порядка управления (например, принятого нумерации версий).

  • не должно документу GUI.

iPhone:

  • должно иметь имя.

  • Приложение должно к определённой .

  • Нужно предоставить для осуществления обратной с разработчиком.

  • Приложение не противоречить Human Interface .

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


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

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


ошибки в релизе приложения высока. попадают в 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 тестирование [18]:



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

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

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

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

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

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

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

Затем 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-миграции с помощью одной галочки. этого публикация из умеет строку подключения без трансформации.



2.11 Выводы

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

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

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

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

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

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

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





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

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

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

Параллельность, возникшая с CI, приводит к более и быстрому поставленных задач .


Список использованных источников


1. Карпов Ю. Г. Теория автоматов. Санк-Петербург : Питер, 2003.

2. Кристофидес H. Теория графов. M : Мир, 1978.

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

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

5. Петренко А. Тестирование на основе моделей. Информационные системы. URL: http://www.info-system.ru/testing/testtestingbasismodels.html. (дата обращения 21.02. 2003)

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

7. Степанченко И. В. Эквивалентное разбиение. Методы тестирования программного обеспечения. Волгоград : РПК "Политехник", 2006.

8. Филиппов В. А., Хатько Е. Е. Проблеммные вопросы автоматизации тестирования для мультизадачных пользовательских комплексов. Информационные, сетевые и телекомуникационные технологии. 2012 . Т. 4.

9. Филиппов В. А., Хатько Е. Е. Генерация тестовых сценариев для мобильных приложений. Информационные, сетевые и телекомуникационные технологии. 2012.Т. 4.

10. Филиппов В. А., Хатько E. E. Модели для мультизадачных пользовательских комплексов. Информационные, сетевые и телекомуникационные технологии. 2012 . Т. 4.

11. Хатько Е. Е. Об одном методе тестирования «мобильных» приложений. Труды МФТИ. 2012 .

12. Хатько Е. Е. Современные проблемы фундаментальных и прикладных наук. Один способ реализации алгоритма генерации тестов в тестировании на основе моделей. Т. 1, с . 92-95. 52. М. 2010.

13. Хатько Е. Е. Москва, Долгопрудный : МФТИ, 2009. Один из подходов к анализу системы тестирования сложных программных комплексов. Современные проблемы фундаментальных и прикладных наук. Т. 1, с. 104 -107.

14. Хатько Е. Е., Филиппов, В. А. Проблемы качества тестирования программного обеспечения для мультизадачных пользовательских комплексов. Качество. Инновации. Образование. 3 2011.Т. 3, с. 32-35.

15. Хэнссон Д. X., Томас, Д. Гибкая разработка ВЕБ-приложений в среде Rails. Санкт-Петербур : Питер, 2008.

16. Шмейлин Б. 3. Современные технологии тестирования WEB приложений. Системы и средства информатики. 2009 г., с. 138-147.

17.Технология UniTESK.. URL: http://www.unitesk.ni/content/section/4/26/. (дата обращения 06.04.2006 г)

18. Andrews A., Offut J., Alexander R. Testing Web Applications by Modeling with FSMs. б.м. : National Science Foundation, 2005.

19. "Definition of betaware in the Free Online Encyclopedia". URL: thefreedictionary.com. (Retrieved. 06.04.2015)

20. Heiskanen Н., Maunumaa М., Katara, М. Test Process Improvement for Automated Test Generation. Tampere: Tampere University of Technology, Department of Software Systems, 2010.

21. IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004

22. Khatko Е, Fillipov V. Mobile applications testing processes metrics and optimization criteria. Software Engineering. 5, 2012 г., Т. 2.

23. Makinen M. Model Based Approach to Software. Helsinki : Helsinki University of Technology, 2007.

24. MSDN Magazine, microsoft.com. URL: http://msdn.microsoft.com/ra-ru/magazine/dd419663 .aspx. (Retrieved. 09.11.2014)

25. Robinson Н. Graph Theory Techniques in Model-Based Testing. 1999.

26. The Next Generation 1996 Lexicon A to Z". Next Generation. No. 15. Imagine Media. Alpha software generally barely runs and is missing major features like gameplay and complete levels. March 1996. p. 29.

27. "The Next Generation 1996 Lexicon A to Z". Next Generation. No. 15. Imagine Media. March 1996. p. 30.

28. "Technology Preview a Scope". Red Hat. 2015.

29. Ural H. Formal methods for test sequence generation. Computer communications. 1992 . Т. 15.

30. Xijiang L., Pomeranz I., Sudhakar M. Techniques for Improving the Efficiency of Sequential Circuit Test Generation. Iowa : University of Iowa. 2015.


Глоссарий

  1. т.п. - тому

  2. т.д. - так далее

  3. дев. - разработка или . (в зависимости от ).

  4. ОС - операционная система

  5. ПО - обеспечение

  6. ПК - персональный

  7. Тест-лид - руководитель тестирования

  8. . - оператор языка SQL, позволяет слиять одной таблицы с другой .

  9. БД - база данных

  10. СУБД - управления базами

  11. apk - формат архивных файлов-приложений для .

  12. Android - операционная для смартфонов, интернет-планшетов, книг, цифровых , наручных , игровых приставок, ,и т.д.

  13. pinch-to-zoom - это контент на экране масштабировать пальцами разводя или их

  14. double tap - двойное

  15. Usability - степень, с продукт быть использован пользователями при определённом использования для достижения целей с эффективностью, продуктивностью и .

  16. Fuzzy testing - тестирования, при которой на программы невалидные, непредусмотренные или данные. 

  17. Monkey - способ тестирования, тестирование без тестого плана и без приложения.

  18. Acceptance - тестирование, которое конечными системы с целью решения о внедрении.

  19. - это обновление программного или оборудования до современной версии.

  20. - распространяющийся по публично-облачной инструмент для управления , совместной и постановки задач по .

  21. Dev - окружение - окружение для .

  22. Pre - delay - предварительная задержка.

  23. UI - это пользователя, он же интерфейс.

  24. TFS - Team Server (TFS) продукт Microsoft, представляющий комплексное , объединяющее в себе управления версиями, данных, построение , отслеживание и изменений по проекту и для совместной работы над по разработке программного .

  25. СI - ContinuousI) -Непрерывная интеграция.

  26. GUI - интерфейс пользователя.

  27. iOS - операционная система для , электронных и носимых проигрывателей, и выпускаемая американской Apple.

  28. 3G - технологии связи 3 — набор услуг, объединяет как высокоскоростной доступ с услугами Интернет, так и радиосвязи, которая канал передачи .

  29. SD - карта - это долговременный карт  (флеш-память), SD Association (SDA) для в портативных устройствах.

  30. SMS - ( message ) вид услуги в сотовых (и других) сетях , короткое текстовое .

  31. MMS - (Multimedia Service) сервис сообщений. Услуга MMS  обмениваться сообщениями на телефон или e-, содержащими видео, , картинки, фотографии и файлы общим до 500 Кб, а также текстовые сообщения до 1000 символов.

  32. GPS - ( Positioning System) система , обеспечивающая измерение , времени и определяющая во всемирной системе

  33. SD - (Secure Memory Card) то формат карт памяти (флеш-), разработанный SD Association (SDA) для в портативных .

  34. ID - это уникальный код, идёт логина на тех или иных .

  35. NET - платформа, на которой программный код.

  36. VCS - Control System - программное обеспечение для работы с изменяющейся .

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

  38. Wi-Fi - (Wireless ) Технологией Wi-Fi один из форматов цифровых данных по .

  39. Program Policies - программы.

  40. App Store - это официальное для магазина Amazon, где найти все те приложения, не доступны на Play.

  41. Samsung - онлайн-магазин мобильного обеспечения, созданный Samsung . 

  42. Yandex Store - приложений для устройств на Android, открытый российской «Яндекс». 

  43. Unit- - процесс в программировании, проверить на корректность модули исходного программы.

  44. Design - дизайн .

  45. Low Level Design - уровень проектирования.

  46. Design - проектирование.

  47. High Design - высокий проектирования.

  48. System - параметры .

  49. Business Case - проектирование.

  50. Business - концептуальное описание деятельности.

  51. Play - магазин , игр, книг, музыки и компании Google и компаний, владельцам устройств с системой Android.

  52. - магазин приложений, онлайн-магазина Store, содержащий приложения для мобильных iPhone и т.д.

  53. TeamCity - это сервер интеграции, готовый к сразу же после . Он поддерживает множество контроля , аутентификации, сборки и прямо из коробки.

  54. - это веб-сайт для тестирования на устройствах на облачных технологий. Он тестировать Android-, iOS- и на реальных устройствах облако.

  55. Analytics - бесплатный , предоставляемый Google для детальной статистики веб-сайтов. собирается на сервере , пользователь только JS-код на страницах сайта.

  56. - компания.

  57. DEV- - ветка разработки.

  58. - веб настройка.

  59. App config'a - приложения.

  60. Framework Migrations - для автоматической миграции данных.

Приложение 1

Рис. 2.1 – Тестировщик приложений



навигационная схема за три моря

Приложение 2



Рис. 2.2 – Проект «Avocado».

c:\users\gnedenkova\documents\мои полученные файлы\l_d3be.tmp.png

Для хранения и прогона тестов мы используем TFS. Например, для проекта Avocado на этом этапе было написано 38 тестов.

Приложение 3
Рис. 2.3 – Сохранение проектов на TeamCity билд-сервере.

https://habrastorage.org/getpro/habr/post_images/95a/0f2/e98/95a0f2e98d9d969e49b24670160e7474.png

Приложение 4
Рис. 2.4 – Таблица критичности багов

таблица определение критичности ошибки

Приложение 5
Рис. 2.5 – Таблица прикладывания скриншота бага со смартфона с пометкой, что не соответствует.

223022949_591751_9961211434105571512.jpg

Приложение 6

Рис. 2.6 – Отчет по тестированию.

отчет о завершении тестирования

Приложение 7


Рис. 2.7 – Примеры багов уровней: blocker, critical и major.

223031747_595237_1648025213324017188.jpg
Приложение 8

Рис. 2.8 – Результат тестирования



https://habrastorage.org/getpro/habr/post_images/ab3/a38/4de/ab3a384dedecc509dbb0cad9d288c416.png

Приложение 9

Рис. 2.9 – В 2012 студии система публикации web-проектов.

c:\users\gnedenkova\desktop\69090b34e2b6e8b40b403200b25c148e.png

Приложение 10

Рис. 2.10 – Последняя версия WebDeploy, запуск EF-миграции.

c:\users\gnedenkova\desktop\af070bb00af536ec33551998fcf49806.png

Приложение 11

Рис. 2.11 – Скриншот мобильного приложения Avocado.

img_0436.png

Приложение 12

Рис. 2.12 – Скриншот TFS работы без внедрения CI.

ccf4cb07-1000-4c76-b19f-a2725bcbff44.jpeg

Приложение 13



Рис. 2.13 – Скриншот TFS работы c внедрением CI.

263df5e3-1afd-462b-8b28-7983721839be.jpeg
Каталог: portal -> docs -> F539967120
docs -> Выпускная квалификационная работа
docs -> №4: Действия работников организаций при угрозе и возникновении на территории организации чрезвычайных ситуаций техногенного характера и пожаров
docs -> Выпускная квалификационная работа
docs -> В. Р. Ильдиряков защита информации при разработке и эксплуатации корпоративных информационных систем и систем обработки персональных данных практические занятия учебно-методическое пособие
docs -> Высшая школа информационных технологий и информационных систем
F539967120 -> Выпускная квалификационная работа


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница