Подходы к автоматизации тестирования веб-приложений

Test Suite — удобный инструмент автоматического тестирования

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

Как выполняются задания по тестированию сайтов

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

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

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

Плюсы:

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

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

Перебор файлов и папок, подбор паролей — тут, я думаю все понятно и так.

Регламентное сканирование и процедуры инвентаризации — для этих целей автоматизированные системы подходят лучше всего.

Минусы:

False positive срабатывания. Очень часто сканеры руководствуясь формальными признаками выявляют уязвимости, которых нет. Классика жанра — при сканировании Single Page Application сканер получает код ответа 200 на все свои запросы и выводит длинный список уязвимостей, которых на самом деле нет.

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

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

Блокирование средствами защиты. Как правило, признаки автоматизированных систем хорошо знакомы разработчикам и они учитывают их при проектировании. Как итог — происходит блокировка (по User Agent, маркерам сканера или частоте запросов).

Не учитывают ошибки логики.

Требуют ручной валидации уязвимостей.

Как получаем нужные данные для анализа?

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

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

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

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

Функциональные тесты

Пример функционального теста

• для мока браузера возьмем jsdom и testing-library;
• для мока сетевых запросов — axios-mock-adapter;
• как тестовый фреймворк будем использовать Jest.

Настраиваем мок

Рендерим компонент

• Настраиваем окружение (API в нашем случае)
• Рендерим компонент
• Делаем какие-то действия в DOM
• Ждём ререндера
• Проверяем что окружение было вызвано так, как мы ожидали (в нашем случае проверяем вызов API).
• Проверяем, что в DOM-дереве находится контент, который мы ожидали увидеть.

Плюсы и минусы

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

Отрефакторенные тесты

низкоуровнево

• Ожидаем, что будет сделан поиск через API, который вернет определенные данные.
• Рендерим компонент.
• Совершаем поиск по строке «ТЕСТ».
• Ждем ререндера.
• Проверяем, что поиск был вызван с нужными параметрами, а на странице есть результаты поиска.

Теперь тест читается как сценарий использования (документация)Тесты теперь высокоуровневыеНовые тесты писать проще – меньше кодаЕсли мы рефакторим верстку, достаточно поправить только pageObjectВадима Макеевасценариине имплементацию.pageObject

Сравнение функциональности TestCafe и Nightwatch

Установка:estCafe: Достаточно одной команды , и можно сразу приступать к написанию и запуску тестов в текущей директории web-проектаightwatch: Хотя установка npm-модуля делается просто — , потребуется мануальная загрузка selenium-standalone-server, webdriver-ов для всех интересующих браузеров, ручное создание конфигурационного файла (А может даже загрузка Java, если она не установлена)

Выборка DOM-элементов:T: Используется механизм Selector-ов — оберток над клиентскими JS-функциями, выбирающими один или множество DOM-узлов; это обеспечивает практически неограниченные возможности для селекции, начиная от простой обертки над или , и заканчивая произвольной логикой прохода по DOM-элементам. При этом TestCafe самостоятельно обеспечивает проверку наличия/отсутствия элементов по заданному Selector-у в течении указанного времени.N: На выбор предоставляется CSS selectors или XPath — в принципе, второго варианта достаточно для решения большинства задач по выборке элементов на странице, хотя это конечно не сравнится с возможностью задания сложной произвольной логики поиска.

Язык написания тестов:T: Из коробки предоставляется возможность написания тестов непосредственно на языке ES2016, что позволяет писать простой и читабельный код тестов на том же языке, что и само web-приложение Это также удобно в случаях, когда требуется импортировать определенный модуль из тестируемого проекта.N: Устаревший ES5-синтаксис и exports-конструкции в исходном коде функционального теста (Возможность прикрутить ES6 все-таки есть, но на костылях)

Поддержка асинхронных операций:T: Все API-функции основаны на Promise-ах, что позволяет описывать произвольную асинхронную логику работы теста, и при этом интегрировать собственные функции со стороны node.js. Благодаря поддержке ES2016, этот код можно записывать при помощи async и await конструкций в последовательном стиле.N: В тесте можно реализовать последовательность команд по анализу и управлению содержимым web-страницы, однако они складываются во внутреннюю очередь событий, и интегрировать собственные асинхронные функции с ними проблематично.

Вставка клиентского кода на лету:T: Легко осуществляется при помощи соответствующего API, поддерживается создание и последующее выполнение клиентских функций, однократное исполнение injected-кода, замена существующих функций в исходной web-странице, а также исполнение клиентских функций в callback-ах node.js-функций с привязкой к тестовому контроллеру.N: Есть функциональность для выполнение JS-кода на клиентской стороне, или даже вставки целого script-блока, но средств интеграции с тест-контроллером не предоставляется. Подходит для простого синхронного интегрируемого JS-кода, но в более общем случае интеграция проблематична.

Описания утверждений и ожиданий:T: По умолчанию — обычный язык утверждений chai/expect, можно использовать и любую другую совместимую библиотеку утверждений.N: Расширенный язык и , включающий средства для описания состояния страницы, в том числе наличия элемента и фокуса на нем, принадлежность к CSS-классу и так далее. Выглядит удобно, однако в первую очередь обусловлено отсутствием полноценной поддержки асинхронных операций в тесте, при необходимости наличия утверждений и ожиданий.

Управление тестируемой web-страницей:T: Предполагает возможность mock-а для блокирующих исполнение сценариев функций , и так далее, с возможностью задания возвращаемого значения. Поддерживаются сложные манипуляции с DOM-моделью, эмуляция пользовательского взаимодействия с элементами управления, и даже возможность приостановки JS-сценария за счет обертывания клиентских JS-функцийN: Поддерживаются команды для непосредственного управления отображаемым окном браузера и подлежащей DOM-моделью, интеграция с клиентским JS-сценарием затруднена

Работа с курсором мыши:T: Предоставляется виртуальный курсор, посредством которого осуществляются hover, click и drag-события для целевым визуальных элементов страницы. В процессе выполнения теста можно наблюдать за перемещением курсора и выполняемыми действиями.N: Средства для работы с курсором вообще есть — это функции из webdriver api, однако работать с действиями, сложнее одиночного левого клика, довольно проблематично — взять хотя бы двойной щелчок.

Реализация взаимодействия с браузером в TestCafe и NightWatch

Фреймворк NightWatch основывается на известной, в некоторой мере уже традиционной, библиотеке Selenium webdriver, преимущества которой включают устоявшееся API, высокую степень документированности и обширное Q&A в интернете, а также универсальный и достаточно низкоуровневый доступ к браузеру… Взаимодействие с браузерами организуется посредством webdriver-ов, по одному на каждый обозреватель.
Основной недостаток — webdriver-ы существуют далеко не для всех браузеров, а также требуют отдельного обновления при смене версии самого браузера, а еще для работы необходимо наличие внешней зависимости от Java. Более подробно о технологии webdriver можно прочесть в http://www.w3.org/TR/webdriver/

Фреймворк TestCafe основан на подходе, в котором взаимодействие с приложением браузера сведено к минимуму — используются только функции открытия окна/вкладки, изменения размера окна, перехода по URL-адресу и некоторые другие.
Взаимодействие с web-страницей производится посредством web-proxy сервера testcafe-hammerhead, осуществляющего загрузку удаленной web-страницы и модификацию исходного JS-кода таким образом, чтобы выполнить шаги функционального теста, посредством интеграции с DOM-моделью, поиска и управления визуальными элементами, выполнение произвольного JS-кода и так далее. (https://github.com/DevExpress/testcafe-hammerhead/)

Метод TestCafe более универсален, поскольку может потенциально работать с любым браузером, поддерживающим HTML5 и ES 5+, в то время как NightWatch требует соответствующий webdriver. Кроме того, это позволяет прогонять тесты не только на локальном браузере, но на любом браузере в сети, включая любые мобильные — без установки какого-либо ПО на телефоне.

Пример тестирования вышерассмотренного web-приложения в браузере на Android показан в следующем видео: https://www.youtube.com/watch?v=2na5jkqvUx0

Однако testcafe-hammerhead имеет и потенциальные недостатки: накладные расходы на анализ и модификацию исходного JS-кода тестируемой страницы, производимые в свою очередь JS-коде ядра Testcafe, а также теоретически некорректная работа тестируемой web-страницы или интеграции теста, если исходный код был проксирован неверно. (К примеру, замещение alert-окна в testcafe можно обойти таким примером http://pastebin.com/p6gLWA75 — и неумешленно или специально “подвесить” его выполнение)

Скриншот-тесты через Storybook

• как компонент работает в начале — показывается кнопка input;
• как компонент грузит данные — показывается loader;
• как компонент показывает поисковые результаты.

• Можно писать на любом фреймворке. Storybook поддерживает практически все популярные фреймворки: Angular, React, Vue. Можно писать истории на чистом HTML и CSS.
• Storybook гарантирует, что компоненты всегда запускаются в изолированной песочнице и не могут афектить друг на друга. 
• В Storybook очень просто описать все возможные состояния компонента.

Loki.js

• Быстрый, относительно своих функциональных аналогов.
• Нативно интегрируется с Docker — вам будет легче настроить его в CI.
• Необязательно поднимать отдельный веб-сервис Storybook. Loki.js умеет работать со Storybook, собранным в статику.

Интеграция

Работа с Loki.js

Минус Loki.js

Creevey

Как работает

Как это выглядит в реальной жизни?Creevey показывает изменения

Платные инструменты автоматизации

Платные инструменты просты в настройке и использованииВ платных инструментах удобнее смотреть измененияВсе видно наглядно

10 примеров эффективного общения для тестировщиков

Перевод

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

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

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

В этой статье описаны 10 примеров ситуаций, когда хорошо развитые коммуникативные навыки тестировщиков могут стать решающим фактором.

Тестовые данные

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

csv(«foo.csv») // данные, разделенные запятой
tsv(«foo.tsv») // данные, разделенные табуляцией
ssv(«foo.ssv») // данные, разделенные точкой с запятой
separatedValues(«foo.txt», ‘#’) // данные разделенные другим символом

На примере небольшого csv файла покажем работу с тестовыми данными:

Gatling при чтении файла использует первую строку как имена параметров, и в последствии при чтении значений сохраняет их под этими именами. Таким образом, в параметр будут подставляться значения с именами ноутбуков, описанных в csv файле.

Чтобы читать csv-файл, необходимо вызвать функцию .

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

При варианте #1 функция вызывается до , таким образом, в переменной будет использоваться первое считанное значение на 5 итераций.

При варианте #2 значение будет считываться перед каждым запросом.

Сколько стоит ручное тестирование сайта?

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

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

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

Абонемент

от 10 500 ₽/мес.

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

подробное описание

Депозитный

от 1 500 ₽/час

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

подробное описание

Apache Bench

Наверное, один из самых простых в использовании и популярных тестов для проверки нагрузки на сайт. Утилита подходит как для простого, так и продвинутого тестирования:

Команда выполнила 10 000 запросов в 50 потоков и, кроме всего прочего, показала скорость и обработанное количество запросов:

Из этого отчета самыми важными данными будут:

• Requests per second — количество запросов в секунду. К примеру если страница состоит из 20 частей (CSS, картинки и HTML), то в нашем примере сервер способен обработать около 40 одновременных пользователей в секунду.
• Time per request (mean) — среднее время на выполнение группы параллельных запросов (в нашем случае 50);
• Time per request (mean, across all concurrent requests) — среднее время на выполнение одного запроса.

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

Особенности тестирования web-приложений:

1. Технологические отличия.

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

Web-приложение работает с использованием принципиально различных технологий.

1. Структурные отличия.

Классическое приложение “монолитное”. Состоит из одного или небольшого количества модулей. Не использует серверы БД, web-серверы и т.д.

Web-приложение — “многокомпонентное”. Состоит из большого числа модулей. Обязательно использует серверы БД, web-серверы, серверы приложений.

1. Отличия режимов работы.

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

Web-приложение работает в режиме “запрос-ответ”, т.е. известно о некотором наборе действий только после запроса на сервер.

Особенности тестирования web-приложений, режим работы

1. Отличия формирования интерфейса.

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

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

1. Отличия работы с сетью.

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

Web-приложение активно использует сетевые каналы передачи данных.

1. Отличия запуска и остановки.

Классическое приложение запускается и останавливается редко.

Web-приложение запускается и останавливается по факту поступления каждого запроса, т.е. очень часто.

1. Разница в количестве пользователей.

Классическое приложение: количество пользователей, одновременно использующих приложение, подвержено контролю, ограничено и легко прогнозируемо.

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

1. Особенности сбоев и отказов.

Классическое приложение: выход из строя тех или иных компонентов сразу становится очевидным.

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

1. Отличия в инсталляции.

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

Web-приложение — процесс инсталляции часто недоступен конечному пользователю. Инсталляция требует специфических знаний. Процесс изменения компонент приложения не предусматривается или требует квалификации пользователей. инсталлятор отсутствует.

1. Отличия в деинсталляции.

Классическое приложение: процесс деинсталляции стандартизирован и выполняется автоматически или полуавтоматически.

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

1. Особенности среды функционирования.

Классическое приложение: среда функционирования стандартизирована и не сильно влияет на функционирование приложения.

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

Установка Yandex.Tank

При желании, вы можете установить Yandex.Tank из пакетов, либо запустить из исходников. Он написан на Python, так что к нему понадобится еще пачка модулей. Я же предпочитаю запускать его в Docker. Это в разы удобнее и быстрее.

Для начала установите себе докер, у меня есть статья по теме — установка docker на centos. После этого создаем директорию для данных танка и кладем туда конфиг нагрузочного теста для сайта.

# mkdir ~/yandex.tank
# touch load.yaml

overload:
  enabled: true
  package: yandextank.plugins.DataUploader
  token_file: "token.txt"
phantom:
  address: www.rambler.ru:443
  header_http: "1.1"
  headers:
    - ""
    - ""
  uris:
    - /
    - /sport/
  load_profile:
    load_type: rps
    schedule: line(5, 30, 1m)
  ssl: true
autostop:
  autostop:
    - http(5xx,10%,5s)
console:
  enabled: true
telegraf:
  enabled: false

token.txt	Текстовый файл с токеном от overload.yandex.net.
www.rambler.ru:443	Адрес сервера, который будем тестировать. Причем это не адрес сайта, так как это доменное имя просто резолвится в ip адрес. Можно задать сразу в виде ip.
Host: www.rambler.ru	Http заголовок, в котором мы передаем имя сайта, который будем нагружать.
/, /sport/	Урлы сайта, к которым по очереди будем обращаться. В данном случае это главная страница и страница /sport. Этот список может быть указан через текстовый файл. Подробности смотрите в документации.
line(5, 30, 1m)	Тип нагрузки. В данном случае это линейный рост запросов с 5 до 30 в течении одной минуты.
http(5xx,10%,5s)	Условие автоматической остановки теста. В данном случае тест завершится сам, если в течении 5 секунд будет 10% пятисотых ошибок.

Создадим текстовый файл с токеном:

# touch token.txt

Не забудьте записать туда токен. Подготовку закончили, можно приступать к тестированию.