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

Требования к составлению тест плана

Полный план тестирования QA готовит после окончания разработки на этапе подготовки к полному тестированию проекта. Документ должен описывать такие пункты:  

• Цель тестирования, описание задачи.

• Описание составляющих системы.

• Какие сущности будут протестированы в ходе теста.

• Окружения, в котором находится тестируемый продукт.

• Описание узких мест системы.

• Порядок тестирования системы (список, что за чем нужно сделать).

• Инструментарий и его назначение (название инструмента и как будем применять).

• Оценка по затраченному времени (список пунктов с оценкой).

• Типы и соотношения тестирования (список с оценкой в процентах).

• Критерии приемки продукта (допустимые проблемы при которых продукт можно выпускать в релиз).

Основные свойства хороших тестов

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

• Хорошие тесты должны максимально защищать от багов при минимальных затратах на сопровождение.

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

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

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

• Тесты должны быть повторяемыми. Они должны давать один и тот же результат при любом количестве запусков.

Компонентные тесты

В микросервисной архитектуре компонентами являются сами сервисы. Здесь нужно изолировать каждый компонент (сервис) от его аналогов или коллабораторов (collaborators) и писать тесты с определенной степенью детализации. Мы можем использовать такие инструменты, как WireMock, для имитации внешней системы или других сервисов. Также мы можем использовать in-memory базы данных для имитации БД, но это создаст немного больше сложностей. В идеале нужно сымитировать все внешние зависимости и тестировать сервис в изоляции. В компонентных тестах нужно запустить сервис локально и автоматически (если у вас есть проект Reactive SpringBoot WebFlux, вы можете использовать WebTestClient и аннотацию @AutoConfigureWebTestClient, чтобы сделать это), и когда сервис запущен, обратиться к его конечной точке, чтобы проверить наши функциональные требования.

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

Шаг 4. Определение покрытия устройств

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

нужно понять, на чем тестировать приложение. Опять же, клиент может запросить конкретные устройства, которые тестировщики должны использовать, или оставить это решение QA-команде.

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

• производители
• размеры экрана
• ОС и их версии
• версии браузера

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

Цели тестирования мобильных приложений

1. Обеспечение корректной работы приложения. Главная цель процесса обеспечения качества – убедиться, что мобильное приложение работает без сбоев. Более того, специалисты проверяют, смогут ли пользователи успешно загрузить программу на свое устройство. Если эксперты используют реальные устройства для тестирования приложений, вы сможете выпустить правильно работающий и безопасный продукт.
2. Прогнозирование пользовательского опыта. Тестировщики ставят себя на место конечных пользователей и взаимодействуют с приложением. В процессе выясняется, насколько интуитивно понятна и логична навигация, а также насколько удобно пользователям открывать приложение в различных ситуациях. Так тестировщики прогнозируют вероятность удаления приложения с устройства.
3. Обеспечение лояльности клиентов. Если вы сделаете приложение удобным и стабильным, пользователи будут вам благодарны. Так у вас получится охватить большую аудиторию и обеспечить себе хорошую репутацию в отрасли.
4. Снижение стоимости разработки приложения. Тестирование требует первоначальных инвестиций, но помогает избежать лишней доработки и перенастройки продукта на последних этапах. В долгосрочной перспективе тестирование экономит вам время и деньги, а также позволяет быстро вывести продукт на рынок. Эксперты по тестированию помогут обеспечить высокие оценки пользователей и снизить стоимость разработки.

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

Полезные ссылки

Подкаст с обменом опытом автоматизации тестирования мобильных приложенийКурс по автоматизацииgithub.com/appium/appium/blob/master/docs/en/drivers/android-uiautomator2.mdbitbar.com/how-to-get-started-with-ui-automator-2-0developer.android.com/training/testing/ui-testing/uiautomator-testing.htmlgithub.com/appium/appium/blob/master/docs/en/drivers/ios-xcuitest.mddeveloper.apple.com/library/content/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/09-ui_testing.htmldeveloper.android.com/training/testing/espresso/index.htmldeveloper.android.com/training/testing/ui-testing/espresso-testing.htmlgithub.com/RobotiumTech/robotiumgithub.com/RobotiumTech/robotium/wiki/Questions-&-Answersselendroid.io/setup.htmlselendroid.io/faq.htmlgithub.com/calabash/calabash-iosgithub.com/calabash/calabash-ios/wiki/DeviceAgentbadoo.com/techblog/blog/2017/01/24/break-limitations-with-calabash-androidgithub.com/google/EarlGreybitbar.com/how-to-get-started-with-earlgrey-ios-functional-ui-testing-frameworkappium.io/introduction.htmlgithub.com/appium/appiumwww.mutuallyhuman.com/blog/2017/04/20/webdriveragent-getting-started-with-automated-ios-testingcucumber.iojunit.org/junit5testng.org/docdeveloper.xamarin.com/guides/testcloud/uitestdeveloper.xamarin.com/guides/testcloud/uitest/intro-to-uitestdoc.froglogic.com/squish/6.0/tutorials-iphone.htmldoc.froglogic.com/squish/6.0/tutorials-android.htmlwww.ranorex.com/help/latest/android-testingwww.ranorex.com/help/latest/android-testing/automation-of-system-appswww.ranorex.com/help/latest/ios-testing

Форма ввода

1. Перечень полей с их описанием и особенностями.
2. Условия сохранения и сброса данных в полях. Когда и какие поля должны сохранять свои значения? Когда очищаться?
3. Ограничения на количество и вид символов.
4. Клавиатура для ввода данных по выбранному полю. Вид клавиатуры: цифровая или символьная. Должна ли клавиатура сдвигать контент при открытии? При каких условиях она должна закрываться?
5. Логика переходов между полями. По кнопке «Далее», по «Next» на клавиатуре.
6. Валидация некорректно введенных данных. Проверки на сервере или на клиенте.
7. Автозапросы на сервер при определенных условиях. Например, если пользователь ввел 6-значный код подтверждения.

Сравнение методов тестирования мобильных приложений

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

Этап 1. Переход на облачные платформы

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

Таблица 1. Оценка сред тестирования

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

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

Надо просто, чтобы предела не было. Тогда и проблем не будет

Если смотреть с точки зрения заказчика, который покупает услуги разработки, то ожидания, что исполнитель сразу предусмотрит все узкие места и оптимально настроит серверное окружение, вполне понятны. Так же, как и недовольство, если что-то пошло не так. А ещё бывает, что система вроде бы работает, а программисты или админы утверждают: всё нужно переделывать и увеличивать бюджет на инфраструктуру. Как тут не огорчиться?

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

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

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

Xamarin Test Cloud

Следующий профессиональный сервис — Xamarin Test Cloud. Более 2500 (не опечатка) реальных устройств! Поддерживаются iOS, Android и полный набор возможностей (скриншоты, автоматизированные скрипты, видео, обещают еще и удаленную отладку и запись в будущем). За все про все — от 99 долларов в месяц. Сервис идеально подходит как разработчикам кросс-платформенных решений (Xamarin, React Native), так и проектам с широкой пользовательской аудиторией (как следствие — высокий охват модельного ряда). Поддерживает автоматизированные скрипты на базе Calabash и Xamarin.UITest.

Старички

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

Программы для автоматизированного тестирования

Разберем основные и посмотрим, зачем они нужны.

MonkeyRunner

MonkeyRunner предоставляет API для написания программ и взаимодействия с Android-устройством не из кода приложения.

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

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

Appium

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

Espresso

Espresso — это фреймворк для разработки UI-тестов под Android. Тесты на этом фреймворке пишут в основном разработчики на Java или Kotlin.

BrowserStack и Ranorex

BrowserStack и Ranorex — платные SaaS-решения, которые настраивают тестовую инфраструктуру и тестируют мобильные приложения в облаке без девайсов.

UI Automator

UI Automator — это утилита. По принципам работы похожа на Espresso, но с помощью нее можно писать тесты на функциональном уровне. Они тестируют поведение приложения end to end.

ADB и XCode command line tools

ADB и XCode command line tools нужны для управления устройством, которое подключено к компьютеру. С их помощью можно управлять несколькими устройствами одновременно и тестировать приложения на фермах устройств.

Postman

Postman — программа для взаимодействия с API сервера напрямую, без использования интерфейса приложения. Иногда это бывает легче, чем искать нужный экран и выполнять нужный сценарий в приложении.

Классификация инструментов

Надстройка

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

1. Модификация поведения (без изменения API).
   Например:
   • дополнительное протоколирование,
   • валидация данных,
   • ожидание выполнения действия в течение определённого времени.
2. Повышение удобства и/ или уровня абстракции API через:
   • использование синтаксического сахара — удобных названий функций, более коротких обращений к ним, унифицированного стиля написания тестов;
   • неявное управление драйвером, когда, например, он инициализируется автоматически, без необходимости прописывать каждое такое действие вручную;
   • упрощение сложных команд вроде выбора события из календаря или работы с прокручивающимися списками;
   • реализацию альтернативных стилей программирования, таких как процедурный стиль или fluent.
3. Унификация API драйверов.
   Здесь надстройка предоставляет единый интерфейс для работы сразу с несколькими драйверами. Это позволяет, например, использовать один и тот же код для тестов на iOS и Android, как в популярной надстройке .

Фреймворк

Фреймворк — это программа для формирования, запуска и сбора результатов запуска набора тестов.

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

Чек-лист для UI-тестирования: что тестировать в первую очередь

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

• Типы данных. Убедитесь, что для определенных типов данных, таких как валюта и даты, можно вводить только допустимые значения.
• Ширина поля. Если определенное текстовое поле предназначено для определенного количества символов, укажите в пользовательском интерфейсе, что введенные данные не должны превышать границу по количеству символов. (Например, поле, которое позволяет использовать 50 символов в базе данных приложения, не должно позволять пользователям вводить более 50 символов в интерфейсе).
• Элементы навигации. Убедитесь, что все кнопки навигации на странице работают и перенаправляют пользователей на нужную страницу или экран.
• Индикаторы прогресса. Иногда приложению нужно время, чтобы выполнить порученную работу, в таких случаях используйте индикатор прогресса, он поможет понять, что работа все еще выполняется.
• Подсказки ввода. В выпадающем меню с сотнями элементов при вводе первой буквы должны остаться только те элементы, которые начинаются с этой буквы, так вы убережете пользователей от просмотра длинной портянки значений.
• Скролл таблиц. Когда данные из таблицы перетекают на следующую страницу, функция прокрутки должна позволять пользователям прокручивать данные, но не трогать все заголовки.
• Ведение журнала ошибок. Когда в системе возникает фатальная ошибка, убедитесь, что приложение записывает сведения об ошибке в специальный файл журнала для последующего просмотра.
• Пункты меню и режим. Убедитесь, что приложение отображает только те пункты меню, которые доступны в определенном режиме.
• Комбинации клавиш. Проверьте комбинации клавиш, правильно ли они работают, независимо от браузера, платформы или устройства.
• Кнопки подтверждения действий. Убедитесь, что пользовательский интерфейс имеет работающую кнопку подтверждения каждый раз, когда пользователь хочет сохранить или удалить элемент.

Очень важно. Тестируйте также сквозные процессы

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

Как стать тестировщиком

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

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

Сделать это можно несколькими способами:

1. Воспользоваться самообразованием. В Сети полно информации по реализации тестинга. И не только для мобильных платформ. Неплохой вариант, но лучше всего он дается не новичкам.
2. Обучиться в ВУЗе. Лучше отдавать предпочтение «разработчикам». Особенно, специализирующихся на мобильных утилитах. В процессе ученики освоят все азы процесса, познакомятся с разнообразными способами воплощения задумки в жизнь. Результат – диплом установленной формы.
3. Пройти спецкурсы. В Москве и других регионах России существуют различные образовательные центры. Они обучают очно, заочно и дистанционно. Предусматривают сегментированное наставничество в выбранном направлении. Обучение длится от нескольких месяцев до года. В конце выдается сертификат.

Последний вариант наиболее популярен на сегодняшний день. Он позволяет быстро научиться тем или иным IT-возможностям по строго намеченному пути.

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

Внимание: немаловажны для процесса обучения такие черты, как усидчивость, целеустремленность и умение работать в команде. P

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

P. S. Большой выбор курсов по тестированию есть и в Otus. Среди них широко представлено и направление автоматизации. Есть варианты как для продвинутых, так и для начинающих пользователей.

На чем запускать тесты

Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:

1. Настоящий девайс.Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
2. Чистый эмулятор.
   Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
3. Docker-образ Android-эмулятора.
   Docker решает недостатки чистых эмуляторов.Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

• Docker image от Avito;
• Docker image от Google;
• Docker image от Agoda.

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

Итоги

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

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

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