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

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

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

Общие рекомендации

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

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

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

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

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

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

Невозможно покрыть автоматизированными тестами все 100% вариантов использования продукта на всех конфигурациях. Ручное тестирование все равно будет использоваться.

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

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

Разбор вариантов стратегий автоматизации тестирования

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

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

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

В данном случае можно выделить 2 разных подхода.

Для «стартапа» могут быть актуальны следующие опции:

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

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

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

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

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

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

Для «корпорации» же актуальны большая часть общих рекомендаций:

Покрытие модульными (unit) тестами необходимо для сокращения времени тестирования.

Потому что в противном случае тестирование может выполняться много часов.

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

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

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

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

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

Заключение

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

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

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

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

Список литературы

1. Автоматизация тестирования iOS-приложений с применением Calabash и Cucumber[Электронный ресурс] / Habr - Коллективный блог. - URL: https://habr.com/ru/company/mailru/blog/244807/. (Дата обращения: 08.05.19).

2. Батыров А. Путеводитель по инструментам автотестирования мобильных приложений [Электронный ресурс] / Habr - Коллективный блог. - URL: https://habr.com/ru/company/badoo/blog/347986/. (Дата обращения: 08.05.19).

3. Бындю А. Тестирование: Ручное или Автоматизированное? [Электронный ресурс] / Habr - Коллективный блог. - URL: https://habr.com/ru/post/145974/. (Дата обращения: 08.05.19).

4. Каща А. Модульное тестирование: 2+2 = 4? [Электронный ресурс] / RSDN - URL: http://rsdn.org/article/testing/UnitTesting.xml

5. Круглов А. Continuousintegration в Яндексе [Электронный ресурс] / Habr-URL:https://habr.com/ru/company/yandex/blog/428972/.(Дата обращения: 08.05.19).

6. Ларин А. Процесс тестирования мобильных приложений [Электронный ресусрс] / Habr-URL: https://habr.com/ru/company/touchinstinct/blog/197060/. (Дата обращения 09.05.19)

7. Мищевский Г. Тестирование. Фундаментальная теория [Электронный ресурс] / Habr-URL: https://habr.com/ru/post/279535/. (Дата обращения: 07.05.19).

8. 7 BestiOSTestingFrameworks: ComparisonGuide[Электронныйресурс] / ApplikeySolutions - URL: https://applikeysolutions.com/blog/7-best-ios-testing-frameworks-comparison-guide/. (Датаобращения: 08.05.19).

9. Abdallah S.A., Moawad R., Fawzy E.E. An optimization approach for automated unit test generation tools using multi-objective evolutionary algorithms // Future Computing and Informatics Journal. 2018. Vol. 3, Issue 2, P. 178-190.

10. Askmeanything. Avito. Android[Электронныйресурс] / Habr - URL: https://habr.com/ru/company/avito/blog/348622/. (Дата обращения: 08.05.19).

11. Braun S.,Elberzhager F., Holl K.Automation Support for Mobile App Quality Assurance - A Tool Landscape //Procedia Computer Science.2017.Vol. 110, P. 117-124

12. FowlerM.ContinuousIntegration[Электронныйресурс] / MartinFowler -URL: https://martinfowler.com/articles/continuousIntegration.html. (Датаобращения: 07.05.19).

13. Fundamentals of Testing[Электронныйресурс] / AndroidDevelopers - URL:https://developer.android.com/training/testing/fundamentals/. (Датаобращения: 08.05.19).

14. Gojare S., Joshi R., Gaigaware D. Analysis and Design of Selenium WebDriver Automation Testing Framework. // Procedia Computer Science. 2015. Vol. 50, P. 341-346

15. Hamdan S., Alramouni S. A Quality Framework for Software Continuous Integration. // Procedia Manufacturing. 2015. Vol. 3, P. 2019-2025f

16. Kolodiy S.Unit Tests, How to Write Testable Code and Why it Matters[Электронныйресурс] /Toptal-URL: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters/. (Датаобращения: 08.05.19).

17. Levels of Testing in Software Testing [Электронныйресурс] / Guru99 -URL: https://www.guru99.com/levels-of-testing.html/. (Датаобращения: 07.05.19).

18. Meiliana, Septian. I., Aliantoa. R. I., Daniel. Comparison Analysis of Android GUI Testing Frameworks by Using an Experimental Study. // Procedia Computer Science. 2018. Vol. 135, P. 736-748

19. Onyaem C. Separate Unit, Integration, and Functional Tests for Continuous Delivery [Электронныйресурс] / Medium - URL: https://medium.com/pacroy/separate-unit-integration-and-functional-tests-for-continuous-delivery-f4dc240d8f2f/. (Датаобращения: 08.05.19).

20. Rauf E.M.A., Reddy E.M.Software Test Automation: An Algorithm for Solving System Management Automation Problems. //Procedia Computer Science. 2015Vol.46, P. 949-956

21. Rupareliya P. Top 10 Automated Testing Tools for Mobile Apps[Электронныйресурс] / Medium - URL: https://medium.com/intuz/top-10-automated-testing-tools-for-mobile-apps-8d9380e1757f/. (Датаобращения: 09.05.19).

22. Singh A.Kr., Prajapati A.Kr., Kumar V., Mishra S. Usage Analysis of Mobile Devices. // Procedia Computer Science. 2017. Vol. 122, P. 657-662

23. SmartphoneTestFarm[Электронныйресурс] / OpenSTF - URL: https://openstf.io/. (Дата обращения: 08.05.19).

24. TDD > The Principle of Single Responsibility[Электронныйресурс] /Philosophical Hacker - URL: https://www.philosophicalhacker.com/post/tdd-is-greater-than-the-principle-of-single-responsibility/. (Датаобращения: 08.05.19).

25. Test Early and Often [Электронныйресурс] / Microsoft Documentation - URL: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/ee330950(v=vs.110). (Датаобращения: 09.05.19).

26. Testing Mobile Apps: A Primer [Электронныйресурс] / Medium - URL: https://medium.com/@FizzyInTheHall/testing-mobile-apps-a-primer-889f62a85e40/. (Датаобращения: 07.05.19).

27. UI/ApplicationExerciserMonkey[Электронныйресурс] / AndroidDevelopers - URL: https://developer.android.com/studio/test/monkey/. (Датаобращения: 08.05.19).

28. Wacker M. Just Say No to More End-to-End Tests [Электронныйресурс] / Google Testing Blog - URL: https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html. (Датаобращения: 09.05.19).

29. What'sTrendingwithMobileTestAutomationFrameworks[Электронныйресурс] / Bitbar- URL: https://bitbar.com/blog/whats-trending-with-mobile-test-automation-frameworks/. (Датаобращения: 08.05.19).

Размещено на Allbest.ru