Авто тестирование программного обеспечения
Автоматизация тестирования с нуля. Часть 1
Добрый день, уважаемые читатели.
Хочу рассказать об опыте построения системы автоматизации тестирования, когда на проекте или совсем нет тестирования, или ее степень минимальная.
Надеюсь статьи будет полезна начинающим автотестерам.
Когда делать автотесты?
Краткий ответ — как можно раньше.
А полный будет раскрыть ниже. В любом случае, когда проект работает 3 года, и все проверялось вручную, жить становится очень монотонно. И парк из 5000 сценариев автоматизировать за месяц-два проблематично. Как правило в таких проектах придется начинать прорабатывать сценарии заново. Потому что это окажется быстрее. И не факт, что старые получится автоматизировать без существенных изменений.
Почему?
Потому что автотетсы:
Накопленные сценарии
Чем больше парк автоматизированных сценариев, там больше вероятность найти регрессию, особенно если при каждом запуске данные изменяются.
Если автотест проходил стабильно и на какой-то ветке упал, то или меняли требования, или баг, или инфраструктура подвела.
Непредвзятость
Если меняли требования — автотест должен отправиться на переделку вместе с переделкой основного функционала. Именно поэтому тестировщики принимают участи в согласовании ТЗ.
Если прогон теста автоматически линкуется к задаче, то никто не сможет сказать, что это не тестировалось. Или наоборот, сможет. В общем проблем точно становится меньше.
Скорость
Если каждый тест удовлетворяет занудным условиям:
Предусловие — Тест — Постусловие
То такие тесты легко автоматизировать.
А потом легко распараллелить. Потому что они получаются независимыми.
Количество потоков — сколько выдержат тестовые сервера и чтобы не мешать другим.
Второй момент это сама по себе скорость. В ручном режиме прокликать создание товара, его поиск и покупку в интернет магазине это 5 минут. 4 браузера. Итого 20 минут. На всего лишь одном небольшом сценарии.
Автотест по этому сценарию проходит за 1,5 минуты. Но на 8 браузерах. (Последняя и предпоследняя версии каждого браузера).
С чего начать?
С пользовательских сценариев.
Ценность атомарных тестов все время падает, особенно на микросервисах. И вообще, в идеальном мире это зона ответственности программиста. Такие ошибки должны быть обнаружены на этапе юнит-тестирования.
QA должен работать от user story. Потому что программист обычно и не знает ее, и не хочет знать.
Соответственно логика 1 тест — 1 пользовательский кейс (бизнес сценарий) наиболее приближена к реальности.
Есть конечно сложности с подготовкой данных, например в случае интернет-магазина процесс оплаты картой требует наличия вещей в корзине, и или данных для нового пользователя, или данных авторизации существующего.
Да, иногда предусловия занимают больше времени, чем тест, но при переиспользовании сценариев сложности не несет.
Какие сценарии автоматизировать
Наименее подверженные изменениям в ближайшей перспективе. Чтобы автоматизация хоть сколько-то прожила.
Или наиболее часто используемые. Есть смысл помогать ручному тестированию в генерации тестовых данных. Например в доске объявлений есть смысл автоматизировать создание объявлений, т.к. далее любой сценарий требует созданного объявления.
Что конкретно делать?
Обычно в проектах есть
Поэтому предлагаю заняться Бэкэндом и Фронтом.
Выбираем сценарий
Допустим, у нас есть интернет-магазин.
Есть админка, есть клиентский и админский фронт.
Есть API, которое все это обслуживает.
С чего начать автоматизацию?
Есть клиенты, есть сотрудники.
У клиента первый кейс — просмотр и поиск товара, добавление его в корзину, и оформление.
У сотрудника самый распространенный кейс — добавление карточки товара.
Какой кейс автоматизируем первым? И как?
Самое важное для магазина — продажи.
Поэтому клиентская история наиболее важна для бизнеса. Поэтому найти товар, поместить в корзину и завершить оформление с любым способом оплаты это первое, что нужно сделать.
По API. Но без фронта. Тут можно поспорить, но скорее всего дизайн поменяется 2-3 раза еще, а вот бэкэнд вряд ли. Так что на 1 этапе придется интерфейс проверять вручную.
Далее сделать проверки на API редактирования карточки товара и ее фронт.
И вернуться к клиентскому. На этом этапе уже будет статистика наиболее частых действий пользователей, и наиболее частых путей клиента. Да, Яндекс Метрика и Вебвизор помогают и тестировщикам.
Нет никакого смысла на первом этапе проверять, работает ли функция оплаты на счет фирмы через сгенерированную платежку, если этой функцией пользуется 0,5% посетителей. Конечно можно задать менеджеру вопрос зачем это тут нужно, но тут не об этом.
Допустим у нас 40% человек платят на сайте картой, 30% наличкой, 20% наложенным платежом и 10% все остальные способы.
Какой тип оплаты будем проверять первым? Конечно картой.
То есть мы должны четко представлять, какой сценарий самый важный для бизнеса в данный момент. И его качество обеспечивать в первую очередь.
Постусловия
Мы насоздавали всего-всего в тестах. Намусорили. Надо бы за собой убрать. Нужно заранее предусмотреть, в каких тестах мы будем за собой убирать, а в каких — нет.
Если товар можно оставить в магазине, и ничего страшного не произойдет, то добавление прав администратора обычному пользователю нужно вернуть. А то следующий тест, связанный с правами может упасть. Или хуже — пройти позитивно, хотя должен был упасть.
Странности
Есть странный подход, когда автоматизируют сценарии, в которых пользователи находили баг. Обычно это очень экзотические сценарии, и тратить ресурс на них нет смысла. Была ситуация когда сломался функционал обновления данных банка-контрагента. Сбоила синхронизация со справочником БИК.
То есть новый БИК не обновлялся. Но новый банк заводился нормально.
Есть ли смысл автоматизировать этот сценарий? Если контрагенты меняются каждый день — может быть. И тогда это была недоработка планирования.
Если это делается 5-6 раз в год, то может лучше более приоритетной задачей заняться?
Что будет дальше?
В следующей статье я расскажу как быстро начать тестировать API, встроить эти тесты в релизы, распараллелить тесты, как подбирать данные для тестов и что нам это даст.
Напомню про эффект пестицида, и как его свети к минимуму.
Технологии: Java + maven + testng + allure + RestAssured + Pict.
Автоматизация тестирования программных систем
Приветственное слово
Здравствуйте, уважаемые хабрапользователи! Хочу представить вашему вниманию статью, в которой речь пойдёт о тестировании программных систем, его автоматизации, а также средствах для этого используемых.
На сегодняшний день уже мало кто сомневается в целесообразности проведения процесса тестирования разрабатываемых программных продуктов, но, к сожалению, не все ясно себе представляют как тестирование грамотно внедрять и применять. Корифеям-тестировщикам моя статья не принесёт практической пользы, а вот интересующихся тематикой новичков порадовать есть чем.
Изначально я не ставлю своей целью охватить всю проблемную область. На это не хватит и серии книг, которую мне, к тому же, не хватит знаний и опыта написать. Основная задача статьи — не растекаясь мыслью по древу, создать у читателя достаточно чёткую картину того, что вообще из себя представляет автоматизация тестирования и когда, а также с чем её едят.
Основные понятия
Начну с небольшого теоретического экскурса.
Итак, под тестированием принято понимать деятельность, выполняемую для оценки и улучшения качества ПО. В общем случае тестирование базируется на обнаружении дефектов и проблем в программных системах.
Автоматизированное тестирование ПО — процесс тестирования программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, производятся автоматически с помощью инструментов для автоматизированного тестирования.
В свою очередь, инструмент для автоматизированного тестирования — это программное обеспечение, посредством которого осуществляется создание, отладка, выполнение и анализ результатов прогона тест-скриптов (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) Сохранить результаты записи:
Результат выполнения
Автоматизация тестирования «с нуля» (нетехническая сторона вопроса)
Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать?
Итак, здравствуйте! Меня зовут Ярослав, я являюсь лидером автоматизации тестирования в Центре развития финансовых технологий Россельхозбанка. В этой статье поделюсь своим опытом организации автоматизации на примере большого проекта РСХБ из 8 команд.
Общая информация по проекту
Большой проект с командами, разрабатывающими общий продукт.
В командах есть QA Manual (Ручной тестировщик).
Направления тестирования — Frontend, Backend.
Изучаем проект
Понимаем цель разработки продукта и кто потребитель
Ответы на эти вопросы помогают понять, на что делать упор в автоматизации. Например, если работаем с юридическими лицами, то делаем упор на тестирование «исполнения законодательства» и переводы по платежам и тд. Если это физические лица, то на основные выполняемые операции: переводы с карты на карту, оплату услуг и тп. Так же важно, чтобы направление автоматизации «смотрело» в целом на продукт, а не на отдельные в нем команды.
Знакомимся с участниками разработки продукта
Выделю ключевых людей:
Владельцы продуктов (Product Owners), они заказчики автоматизации в команде.
QA каждой команды. Они — это клиенты инструмента автоматизации, их уровень счастья — это показатель успеха.
Лидер ручного тестирования. Помогает в организации процесса и во взаимодействии с ручным тестированием.
Лидер разработки Frontend. Он влияет на стабильность и качество автотестов.
Специалист по закупке. Решит вопросы выделения техники, в основном с серверным железом.
Изучаем каждую команду
Собираем информацию о том, какую часть проекта разрабатывает команда.
Разбираемся в направлении — Frontend, Backend или всё сразу.
Разбираемся с тем, как QA тестируют свою часть продукта.
Выясняем, на каком уровне QA manual знаком с автоматизацией.
Находим боли в тестировании и что приоритетно закрыть автоматизацией.
Формируем требования к автоматизации и заказываем ресурсы
Что мы собрали?
У нас есть 8 команд.
Есть 11 QA инженеров.
Есть направления тестирования Frontend, Backend + будем «ходить» в Базу данных.
90% QA manual никогда не занимались автоматизацией.
Исходя из данных, формируем требования к автоматизации
У нас нет задачи делать какие-то инновационные решения, поэтому придерживаемся классики:
В качестве языка программирования выбираем Java — так будет проще найти специалистов.
Нужно тестировать Frontend. Берем Selenium.
Нужно тестировать Backend. Взаимодействуем с ним через REST. Берем REST-assured.
Нужно «ходить» в базу данных. Возьмем стандартные библиотеки из Java.
Нужно либо обучить QA manual разработке автотестов, либо нанять армию из N автоматизаторов. Мы думаем о расходах проекта на тестирование, поэтому убиваем 2-х зайцев сразу. Берем Cucumber.
Нам нужна отчетность с красивыми графиками. Берем Allure.
Получился следующий стек технологий: Java, Selenium, REST-assured, Cucumber.
Оцениваем силы автоматизаторов
Поскольку их нет, берем 1 автоматизатора на 5 команд (больше 5-и не потянет).
Автотесты нужно где-то запускать
Что нам понадобится?
Машина для Jenkins. 1 штука. Через него реализуем удаленный запуск.
Машина под Slave Jenkins. Как agent для Jenkins.
Машина под Selenoid. Для параллельного запуска тестов.
Делаем демо нашего инструмента
Наше демо будут смотреть все: владельцы продуктов, QA инженеры, разработчики, аналитики и тд. Значит ориентируемся на понимание для всех.
Берем команду в качестве первой «жертвы» автоматизации. Ребята разрабатывают Frontend. Нам нужна наглядность.
Делаем 5-10 автотестов. Записываем на видео.
Обязательно после прогона показываем Allure. Красивые графики любят все.
Рисуем «инфраструктуру автотестов». Главное, чтобы было просто и понятно.
Обозначаем главную цель автоматизации.
Демонстрируем эффект от автоматизации.
Делаем сравнительные тесты. Ручное прохождение и автоматизированное.
Показываем, как создаются сценарии.
Показываем планы автоматизации (когда появятся тот или иной функционал).
Показываем, как будет происходить внедрение автоматизации в команды.
Подготавливаем UI к автоматизации
Для обеспечения надежности, стабильности и качества автотестов, необходимо раскидать якоря на UI. Централизованно через лидера Frontend и дополнительно через владельцев продукта проставляем атрибут для UI-элементов “data-test-id“ или с любым другим названием. Смысл в том, чтобы со стороны UI проставить этот атрибут во всех элементах типа «Таблица, поле для ввода, кнопка» и тд. Если коротко, то на всех элементах, с которыми взаимодействуем, это даст +300% к надежности автотестов. Переезд элемента в другое место или изменение его содержимого никак не повлияют на проверку автотестом. Делаем этот момент обязательным для всех новых фич.
Разрабатываем автотесты
Делим команды между автотестерами.
Разрабатываем каркас проекта для автоматизации. Все по шаблону.
Подготавливаем набор Cucumber шагов для работы с Frontend, основным направлением в тестировании. Выносим шаги в отдельный проект и делаем из него подключаемый артефакт.
Настраиваем Selenoid и Jenkins.
Начинаем подключать команды к автоматизации. При подключении команды все сводится к тому, чтобы создать репозиторий, загрузить каркас, создать Job в Jenkins по шаблону, обучить QA работе с Cucumber, работе с Git и средой разработки.
После обучения QA manual самостоятельно пишут автотесты. Один раз за спринт автоматизатор приходит в команду и принимает написанные автотесты, делает правки и вливает в основную ветку. На этом этапе ребята качают уровень написания правильных сценариев, а мы получаем качественные проверенные сценарии.
После встречи со всеми командами у автоматизатора в спринте остается еще 5-6 свободных дней. Это время тратим на разработку Cucumber шагов.
В конце спринта на продуктовом демо показываем результаты по командам и делаем анонсы новых фич в инструменте.
Результаты
6 спринтов (60 дней), 8 команд, 2 автотестера и 11 ручных тестировщиков — имеем 50% покрытия регресса проекта автотестами. Это с учетом подключения команд (подключались постепенно) и разработки шагов.
4 вещи, о которых нужно помнить при разработке с таким подходом
Ручной тестировщик — это клиент
QA инженер — прямой потребитель инструмента автоматизации. Их уровень комфорта, счастья и количество автотестов — это показатель качества нашей работы. Если один из показателей падает, значит нужно что-то менять. Иначе все посыпется.
Ориентация на выгоду для проекта
Нужно всегда помнить, что содержание разработчиков, тестировщиков, аналитиков и других специалистов стоит денег. В конечном итоге наша цель их сэкономить.
Как мы их экономим?
Автотестами: находим дефекты запуская их каждый день.
На каждом этапе тестирования сокращаем время регресса.
Все это приводит к более быстрому выпуску продукта в промышленную эксплуатацию.
Не работает? Меняй!
Не нужно бояться ошибок. Их будет очень много в разработке, в общении с командами, во взаимодействии с QA инженерами, в демо. Главное увидеть, что «что-то» не работает и менять подход до тех пор, пока все не будут в восторге. Всё делаем для людей. Не для себя.
Кайфуй
Наверное, самое главное в любой работе — это получать удовольствие. До сих пор с умилением смотрю на автотесты. Я тоже был QA manual инженером и прекрасно понимаю, насколько нудно тестировать регресс раз за разом. Автотесты — это бальзам:)
10 лучших инструментов для автоматизации тестирования ПО
Привет, Хабр! Представляю вашему вниманию перевод статьи «Top 10 Automated Software Testing Tools» автора Pratik Satasiya.
Боб Иган, директор по исследованиям Sepharim Research, говорил о мобильной безопасности. Он выступил с заявлением на Enterprise Mobility Trends 2016:
«Современный десктоп на самом деле не десктоп, а опыт, который нужен в данный момент».
Он также добавил, что мы попадаем в поколение, где будут разработаны приложения, специально предназначенные для простой и эффективной работы. Я согласен с этим и считаю, что мы очень зависимы от минимизации наших рабочих усилий с помощью различных инструментов.
Внедрение приложений, уменьшающих усилия, быстро охватывает следующие отрасли:
Вот обзор самых популярных инструментов автоматизации тестирования программного обеспечения, которые помогут тем, кто занимается тестированием программного обеспечения.
10 лучших инструментов для автоматического тестирования программного обеспечения
1. Selenium
Selenium — это среда тестирования для тестирования веб-приложений в различных браузерах и платформах, таких как Windows, Mac и Linux. Selenium помогает тестировщикам писать тесты на разных языках программирования, таких как Java, PHP, C #, Python, Groovy, Ruby и Perl. Selenium предлагает функции записи и воспроизведения для написания тестов без изучения Selenium IDE.
Selenium с гордостью поддерживает некоторых из крупнейших, известных производителей браузеров, которые уверены, что Selenium является родной частью их браузера. Selenium, является основой для большинства других инструментов тестирования программного обеспечения в целом.
2. TestingWhiz
TestingWhiz — это инструмент автоматизации тестирования со сценариями без кода от Cygnet Infotech, поставщика ИТ решений 3-го уровня CMMi. Редакция Enterprise инструмента TestingWhiz предлагает полный пакет различных решений для автоматизированного тестирования, таких как веб-тестирование, тестирование программного обеспечения, тестирование баз данных, тестирование API, тестирование мобильных приложений, обслуживание набора регрессионных тестов, оптимизация и автоматизация, а также межбраузерное тестирование.
TestingWhiz предлагает различные функции, такие как:
3. HPE Unified Functional Testing (HP – UFT ранее QTP)
HP QuickTest Professional был переименован в HPE Unified Functional Testing. HPE UFT предлагает автоматизацию тестирования для функционального и регрессионного тестирования для программных приложений.
Язык сценариев Visual Basic Scripting Edition используется этим инструментом для регистрации процессов тестирования и управления различными объектами и элементами управления при тестировании приложений.
QTP предлагает различные функции, такие как:
4. TestComplete
TestComplete — это функциональная платформа тестирования, которая предлагает различные решения для автоматизации тестирования настольных, мобильных приложений компанией SmartBear Software.
TestComplete предлагает следующие функции:
5. Ranorex
Ranorex Studio предлагает инструменты автоматизации тестирования, которые охватывают тестирование всех десктопных и мобильных приложений.
Ranorex предлагает следующие функции:
6. Sahi
Sahi — инструмент для автоматизации тестирования веб-приложений. Sahi с открытым исходным кодом написан на языках программирования Java и JavaScript.
Sahi предоставляет следующие возможности:
7. Watir
Watir — это инструмент тестирования с открытым исходным кодом, состоящий из библиотек Ruby, для автоматизации тестирования веб-приложений. Это произносится как «вода».
Watir предлагает следующие функции:
8. Tosca Testsuite
Tosca Testsuite от Tricentis использует автоматизацию тестирования на основе моделей для автоматизации тестирования программного обеспечения.
Tosca Testsuite обладает следующими возможностями:
9. Telerik TestStudio
Telerik TestStudio предлагает одно решение для автоматизации тестирования десктопных, мобильных приложений, включая тестирование пользовательского интерфейса, нагрузку и производительность.
Telerik TestStudio предлагает различные совместимости, такие как:
10. Katalon Studio
Katalon Studio — это бесплатное решение для автоматизации тестирования, разработанное компанией Katalon LLC. Программное обеспечение построено на основе сред автоматизации с открытым исходным кодом Selenium, Appium со специализированным интерфейсом IDE для тестирования API, веб-приложений и мобильных устройств. Этот инструмент включает в себя полный пакет мощных функций, которые помогают преодолеть общие проблемы в автоматизации тестирования веб-интерфейса.
Katalon Studio состоит из следующих функций:
В индустрии тестирования программного обеспечения должно быть много разных инструментов автоматического тестирования программного обеспечения.
А что из инструментов автоматического тестирования используете вы?