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

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное  учреждение

Высшего профессионального  образования

«Волгоградский  государственный технический университет»

(ВолгГТУ)

Кафедра «Системы автоматизированного проектирования и поискового конструирования»

 

 

 

Семестровая работа

По предмету

«Теоретические основы автоматизированного управления»

На тему

«Разработка и поддержка мобильных приложений»

 

 

 

Группа:

Выполнил

Проверил:

№ Зачетной книжки:

 

 

 

 

 

 

Введение

Мобильные пользователи ожидают, что устанавливаемые ими приложения стабильны, быстро реагируют на действия, безопасны, имеют простой пользовательский интерфейс, работают в режиме “24 часа и 7 дней в неделю” (особенно в приложениях, взаимодействующих с сервером). Обеспечить такое качество возможно только в том случае, когда разрабатываемое приложение активно тестируется во время разработки и, особенно, перед заливкой приложения в мобильные «маркеты».

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

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

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

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

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

IDEF0 диаграммы

1) As-is диаграммы:

As-is: Mobile application testing

 

As-is: Mobile application testing(disassembling)

 

As-is: implementing first version of application

 

As-is: Further development process

 

As-is: New features implementation

 

2) To-be диаграммы:

To-be: mobile application testing

 

To-be: mobile application testing (disassembling)

 

To-be: implementing first version of application

 

To-be: further development process

 

To-be: New features implementation

 

IDEF3 диаграммы

1) As-is диаграммы:

As-is: Build testing(manual)

 

As-is: New feature build manual testing

 

As-is: Final testing

 

2) To-be диаграммы:

To-be: Build testing (auto)

 

To-be: Build testing (manual), неизменна по сравнению с “As-is: Build testing (manual)”

 

To-be: New feature build manual & auto testing

 

To-be: Final testing, неизменна по сравнению с “As-is: Final testing”

 

DFD диаграммы

1) As-is диаграммы:

As-is: Creating technical specification for new application

 

As-is: Time estimates and software choosing for developing

 

As-is: Starting stage of developers and testers activities

 

As-is: Task assignment for team

 

As-is: Task assignment for manual testers

 

2) To-be диаграммы:

To-be: Creating technical specification for new application

 

To-be: Time estimates and software choosing for developing

 

To-be: Starting stage of developers and testers activities

 

To-be: Task assignment for team

 

To-be: Task assignment for manual testers, неизменна по сравнению с “As-is: Task assignment for manual testers”

 

 

UML диаграммы

Use case diagram

 

Class diagram

 

 

Sequence diagram

 

 

 

 

 

Component diagram

 

 

Заключение

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

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

В диаграммах to-be мы видим внедрение автоматизированного тестирования в процесс разработки приложения. Автоматизация тестирования, так же как и непосредственно разработка требует оценки сроков написания кода тестов на каждом этапе развития приложения, так же как и у разработки – оценивается стоимость программного обеспечения для внедрения автоматизации. Некоторые инструменты автоматизации стоят больше ста тысяч долларов в год. Автоматизация тестирования – это полноценная разработка софта, поэтому все что делается непосредственно для разработчиков, переносится и в автоматизацию.

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

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