http://habrahabr.ru/post/243097/

В статье пойдет речь о тестировании в сжатые сроки с использованием инструмента 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 (и на чем я пишу для этих решений). Подход «главное, знай хорошо несколько самых главных инструментов и умей применить» заметно облегчает жизнь и тестировщику, и работодателю, и рынку в целом.