Как выбрать тесты для автоматизации

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

Приветственное слово

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

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

Основные понятия

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

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

В свою очередь, инструмент для автоматизированного тестирования — это программное обеспечение, посредством которого осуществляется создание, отладка, выполнение и анализ результатов прогона тест-скриптов (Test Scripts — это наборы инструкций для автоматической проверки определенной части программного обеспечения).

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

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

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

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

Конфигурационное тестирование – выполнение одних и тех же тестов в разных условиях. То есть когда один или несколько компонентов архитектуры системы требуется проверить в разном окружении, обычно заявленном в изначальных требованиях. Например: поддержка СУБД от разных производителей, работа в разных клиентских браузерах, использование в нескольких ОС и т.п. То есть некий аналог регрессионного тестирования, но в рамках одной версии системы.

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

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

«А зачем?»

Как автоматизировать тестирование?

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

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

На финишной прямой

Чтобы принять окончательное решение о целесообразности применения автоматизации, обычно советуют ответить на возникающий естественным образом в данной ситуации вопрос: «превалируют ли в нашем случае преимущества над недостатками?». Если недостатки в конкретном случае неприемлемы, то от автоматизации стоит воздержаться.

Выбор инструмента

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

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

HP QuickTest Professional

Средство автоматизации от кампании Hewlett-Packard. Распространяется на платной основе (8000-10000 USD). Является основным инструментом автоматизации функционального тестирования от данного производителя. Позволяет автоматизировать функциональные и регрессионные тесты через записи действий пользователя при работе с тестируемым приложением, а потом исполнять записанные действия с целью проверки работоспособности ПО.
Записанные действия сохраняются в виде скриптов.
Скрипты могут быть отображенные в инструменте как VBScript (expert view), или же как визуальные последовательные шаги с действиями (keyword view).
Каждый шаг может быть отредактирован и на него можно добавить точки проверки (checkpoint), которые сравнивают ожидаемый результат с полученным.

IBM Rational Functional Tester

Тоже платный, но не настолько («всего-то» 6000 USD).
Rational Functional Tester предоставляет тестировщикам средства автоматизированного тестирования, позволяющие выполнять функциональное тестирование, регрессивное тестирование, тестирование пользовательского интерфейса и тестирование управляемое данными.
Много описательной информации о нём не дам, а лучше приведу практический пример.

Пример использования

Будет использована интеграция IBM Rational Functional Tester со средой разработки Microsoft Visual Studio. Для создания функционального теста необходимо выполнить следующие действия:

1) В среде разработки Microsoft Visual Studio создать новый проект «Functional Test Project»:

2) Выполнить запись пользовательских действий с тестируемым приложением:

3) Создать проверочную точку в процессе выполнения записи. Проверочная точка также будет выполнять проверку значения в выпадающем списке:

4) Сохранить результаты записи:

Результат выполнения

Источник

Как правильно готовить автоматизацию или Что покрывать тестами в первую очередь

Привет, это Эрик Бурыгин, я техлид курса «Автоматизатор тестирования на Java» в Яндекс.Практикуме и лид в Яндексе. Каждый ручной тестировщик считает, что автоматизация — это круто и её непременно нужно втащить в проект. Что может быть лучше, чем полное покрытие автотестами продукта, когда тесты гоняются 24/7 и отлавливают баги? Вот прочитал я эти строки, и захотелось ещё раз всё заавтоматизировать!

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

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

Поймите, что автоматизировать в первую очередь

Для начала нужно чётко определиться с тем, что автоматизировать в первую очередь!

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

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

Итак, мы делаем приложение по продаже кастомных байков Custom Bike для платформ iOS и Android. Полный регресс приложения — это 2500+ кейсов на платформу и примерно несколько недель человеко-часов. Для написания тест-кейсов мы используем Testpalm от Яндекса. Релизимся часто. Но как бы мы не стремились ускорить процесс выкладки, регрессы оставались узким местом. Тестировщики утопали в них, теряя всякую мотивацию. Конечно, можно было нарастить команду, но это путь вникуда, так как новые фичи выкатываются каждый релиз и регресс становится всё необъятнее.

Вот мы и решили втащить в проект автоматизацию и, как вы наверное догадались, начали с регресса, а именно — с регресса Android-приложения. Благо культура автоматизации тестирования в команде была на высоком уровне — на тот момент мы очень преуспели в автоматизации веба и API. Но как всегда, без ложки дёгтя не обошлось — наша экспертиза в автоматизации мобилок была близка к нулю, а изучать новое было проблематично, ибо задач и так хватало. Как сейчас помню фразу: «Чтобы автоматизировать Android, нужно становиться Android-разработчиком».

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

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

Как понять, что автоматизировать

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

Testpalm позволяет без проблем выгрузить весь пул кейсов, что у нас есть.
Это можно сделать с помощью Python и библиотеки Requests. Пример:

Список кейсов получен, но нам нужна статистика, а пока мало что можно посчитать. Чтобы посчитать статистику, нужны маркеры. Testpalm отлично с этим справляется — там есть теги, поэтому мы начали при каждом сборе смоука добавлять тег-версию релиза: Android_4.11, Android_4.12, Android_4.13 и т. д. Это позволило нехитрым способом сосчитать, сколько раз каждый кейс был задействован в смоуках из выгруженного джейсона. Пример:

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

Пример получившегося списка:

ps://testpalm.ru/testcase/ Диплинки facebook 8
ps://testpalm.ru/testcase/ Реклама в листинге 8
ps://testpalm.ru/testcase/ Карточка мото 7
ps://testpalm.ru/testcase/ Геосаджест 7
ps://testpalm.ru/testcase/ Опция турбо 7
ps://testpalm.ru/testcase/ Опция продвижение 7
ps://testpalm.ru/testcase/ Опция поднятие 7
ps://testpalm.ru/testcase/ Реклама в карточке мото 6
ps://testpalm.ru/testcase/ Пожаловаться в карточке мото 6
ps://testpalm.ru/testcase/ Диплинки на выдачу 5
ps://testpalm.ru/testcase/ Смена региона 5

Теперь точно понятно! Но чтобы всё было по красоте, осталось обернуть полученные данные в табличку. Для хранения документации мы используем вики, и всё, что нужно было сделать — добавить вики-разметку в выводимый результат. Пример кода:

Так мы получили красивую легкочитаемую табличку.

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

Теперь табличка стала чище, и в ней остались только те кейсы, на которые нужно обратить внимание и завести задачи на автоматизацию. Для удобства добавили ещё один столбец — «Задача на автоматизацию». Пример кода:

Пример таблички в вёрстке:

Так как у нас помимо приложения Custom Bike есть и другие проекты, каждый из которых поддерживает iOS и Android, нужно было сделать скрипт формирования статистики более гибким. Мы ещё немного доработали код, и теперь при запуске скрипта можно передавать в него проект и платформу, получая статистику для нужного приложения. Пример запуска скрипта:

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

Вот теперь всё стало по красоте!

Заключение

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

В смоуке, как правило, все кейсы разные, и с помощью нашего подхода мы перекрываем большую часть уникальных сценариев, что позволяет наработать хорошую кодовую базу. С ней можно двигаться дальше и писать тесты по образу и подобию уже имеющихся. Ещё хочется отметить, что такой подход подойдёт как устоявшимся проектам, так и стартапам. И не забываем про хорошую и понятную отчётность — будет что показать руководителю и менеджерам. Кроме того, отчётность позволит легко ориентироваться в тестовом покрытии — с этой задачей отлично справится Allure.

Надеюсь, статья показалась вам интересной. Если у вас остались вопросы или есть собственные идеи по поводу автоматизации — пишите в комментарии, обсудим.

Источник

Как выбрать тесты для автоматизации

При автоматизации тестирования очень часто приходится сталкиваться с вопросом «Что автоматизировать в первую очередь?» Автоматизация не делается ради автоматизации: хочется видеть результат процесса, который давал бы положительный ROI (подробнее о расчете ROI можно прочитать тут).

Почему важно использовать автоматизацию?

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

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

Итак, каковы критерии выбора тест-кейсов для автоматизации?

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

Какие типы тестов следует исключать из тестирования автоматизации?

Перечислим случаи, при которых тесты-кейсы нужно отфильтровать от автоматизации:

Что дальше?

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

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

По клику на картинку откроется полная версия.
Y – условие выполняется
N – Условие не выполняется
Таким образом, мы получаем 3 тест-кейса, которые можно начать автоматизировать, и 2 тест-кейса, не требующих автоматизации. Мы выполнили самую важную задачу и добрую половину работы: беспорядок новой темы превращается в подробный план того, что нужно сделать.

Вывод

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

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

Любите тестировщика в себе, а не себя в тестировании!

Источник

Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать

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

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

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

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

Автоматизируйте ваши смоук тесты

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

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

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

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

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

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

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

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

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

Автоматизируйте обширные тесты

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

Автоматизируйте тесты, требующие нескольких конфигураций

Автоматизируйте ваши тесты производительности

Ваш следующий шаг

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

Источник