В статье пойдет речь о тестировании в условиях сжатых сроков с использованием таких инструментов, как Selenium и JMeter, а так же о том, как не запороть проект тестирования в условиях дефицита компетентных сотрудников.
Как тестировщик, я люблю когда всё по порядку, но жизнь переполнена грязными хаками. Я люблю автоматизировать, подвязав Selenium к Python, но когда встречаюсь с проблемой ограниченности ресурсов, бросаюсь за тот инструмент, который позволяет сделать «всё то же самое, но быстрее». В этом посте я расскажу, что JMeter — прекрасный инструмент как для нагрузочного, так и для функционального тестирования.
Передо мной постановили задачу протестировать API для мобильного приложения. Особенности её были следующие:
- Сроки, как никогда, сжаты.
- Спецификация всех методов есть, но меняется она буквально на лету.
- Проект запутанный. Если погибну в горах или заболею, вводить в проект нового человека будет очень дорого и сложно.
- В качестве системы CI используем Jenkins. Тесты должны встать легко без какого-либо редко используемого, сырого и чересчур сложно настраиваемого плагина.
- Обязательное нагрузочное тестирование, но времени на его проведение мало.
- Само мобильное приложение для данного API пишет совершенно другая команда из другого города. Единственный способ протестировать — просматривать ответы на запросы.
Руки привычно потянулись к Python, но что-то переключилось в голове. «Дорогой друг, — сказал я себе, — если ты единственный в команде человек, который будет писать на Python, то кто будет разбираться с тем, что ты написал и продолжать работу в случае твоего отсутсвия?».
Нужно было явно искать другой инструмент. И тут я посмотрел на горячо любимый JMeter c совершенно другой стороны: JMeter, конечно, оставляет желать лучшего внешне, но зато вместо тысячи мелких скриптов перед нами будет понятная структура тестов. Поэтому я могу просить коллег запускать выборочные тесты вместо меня с любой машины. Даже программисты оценили, что это гораздо удобнее, чем «прогонять руками» для отладки.
В нём из коробки есть всё (ну почти), что нужно:
- Работа с переменными, регулярными выражениями, парсинг JSON, работа с куки и еще огромный мешок плюшечек.
- Простой и доходчивый плагин к Jenkins, который позволит всё подключить.
- Для нагрузочного тестирования мне не придется писать новые сценарии, можно лишь немного модифицировать существующие.
Единственное, что немного смутило — Jenkins рассматривает JMeter исключительно как инструмент нагрузочного тестирования, поэтому история найденных багов была во вкладке Perfomance report.
Коротко о самом процессе тестирования:
- Стандартный Thread group на 1 Virtual user.
- Каждая группа тестов заключена в Simple Controller (он обладает только одним отличительным свойством: все запросы идут один за другим. Это то, что нужно, прямо как в тест-кейсе).
- Каждый отдельный тест-кейс также заключен в отдельный Simple Controller. Это совсем простые кейсы. Например, проверка, вернется ли 401 код при попытке залезть без авторизации, сделана отдельным тест-кейсом.
Вместо тысячи слов. Вот так выглядит небольшой кусочек готового теста:
Один из многих тестов. Группы разбиты в Simple Controller. Http request, Regular Expression Extractor, Response Assertion, немного User Defined Variables, Random Variable и вот практически всё.
Почти любой тест начинается с создания необходимых пользователей. Здесь единственное «захардкоженное место» — авторизация админа для создания нового элемента в базе данных.
Что забавно, был реализован метод для создания пользователя, а вот удаление происходило только вручную через админку. Я решил не усложнять логику каждого отдельного кейса, добавляя отдельные тесты на Selenium для очистки пользователей, и не стал удалять созданных пользователей внутри самого теста. За это получил благодарность от программистов: когда начинали писать паджинатор для страниц админки, в базе уже были тысячи тестовых пользователей.
Для проверки результата после каждого запроса идёт длинная череда assertions. Она проверяет верность пришедших данных: http-коды ответов, сообщения.
Я отключил все графики и отчеты, кроме simple tree view для отладки. Все баги можно будет посмотреть прямо в Jenkins, а для нагрузочного тестирования удобнее было заливать сразу на LoadSophia с их фирменным плагином и забирать уже там.
Вот как няшно для программиста выглядит сообщение о том, почему не прошла очередная сборка:
И более детально. Ждали 400 код — вернулся 404:
Итог этого чернокнижия и мракобесия:
Из 1200 часов, заложенных на разработку, в сумме на написание и актуальное поддержание автотестов ушло 50 часов. На исправление багов — 70 часов. Причем около половины из них была связана с недопониманием заказчика и разработчиков. Результат очень хороший. Альтернатива проверять все вручную отняла бы едва ли не больше времени, чем ушло бы на программирование. Программисты видели сразу, как что-то идёт не так, во всей системе при каждой новой сборке.
В моё отсутствие проблем с запуском и изменением автотестов не было как у программистов, так и у тестировщиков. Иногда тесты меняли прямо в блокноте, поскольку *.jmx — это тоже XML.
Для проведения нагрузочного тестирования я просто отключал ненужные тесты на время, вычисляя, где слабые места системы, какие тесты проходят медленно. Не возникало никаких проблем с использованием новых плюшек JMeter. Всё документировано и всё понятно.
Из трудностей, с которыми столкнулся:
- Плагин для JMeter, реализующий oAuth авторизацию, сильно устарел и не работает с oAuth 2.0. Небольшую часть функционала, связанную с авторизацией через социальные сети, тестировать приходилось отдельно.
- Подвязывать Selenium к JMeter — тоже сомнительное удовольствие. UI Админки тестировалось также отдельно.
- Для людей, не сталкивавшихся с интерфейсом JMeter, первое знакомство заканчивается
отслоением сетчаткилегким расстройством.
P.S. Небольшое лирическое отступление. В одной из недавних статей говорилось о способе сократить работу тестировщика через декомпозицию и, что более важно, о проблемах рынка тестирования. Одним из ответов рынка на «замкнутый круг тестировщиков», описываемом в начале статьи, является стандартизация навыков тестирования. С ней работодатель станет более уверен, что найдет на рынке необходимого специалиста, способного решить проблему. Тестировщик же будет знать, что с полученными знаниями он не потеряется на рынке. В данном случае сделать функциональное тестирование через JMeter — совсем не академичное решение. Но оно сократило временные затраты и полкило нервов при аналогичном результате. У меня был знакомый, знающий только самый элементарный базис JMeter и Selenium, но был взят с распростертыми объятиями в одну очень уважаемую фирму. Ни на одном собеседовании в жизни меня не спрашивали, знаю ли я какую-то редко используемую библиотеку. Спрашивали в основном опять же про JMeter, Selenium (и на чем я пишу для этих решений). Подход «главное, знай хорошо несколько самых главных инструментов и умей применить» заметно облегчает жизнь и тестировщику, и работодателю, и рынку в целом.
Автор: htc-cs
