JMeter як щодо зручний і практичний засіб для тестування API

В статті піде мова про тестування в умовах стислих термінів з використанням таких інструментів, як Selenium і JMeter, а так само про те, як не занапастити проект тестування в умовах дефіциту компетентних співробітників.
image

Як тестувальник, я люблю коли все по порядку, але життя переповнена брудними хаками. Я люблю автоматизувати, підв'язавши 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 код при спробі залізти без авторизації, зроблена окремих тест-кейсом.
Замість тисячі слів. Ось так виглядає невеликий шматочок готового тіста:
image
Один з багатьох тестів. Групи розбиті в Simple Controller. Http request, Regular Expression Extractor, Response Assertion, трохи User Defined Variables, Random Variable і ось практично всі.

Майже будь-який тест починається з створення необхідних користувачів. Тут єдине «захардкоженное місце» — авторизація адміна для створення нового елемента в базі даних.

Що забавно, був реалізований метод для створення користувача, а ось видалення відбувалося тільки вручну через адмінку. Я вирішив не ускладнювати логіку кожного окремого кейса, додаючи окремі тести на Selenium для очищення користувачів, і не став видаляти створених користувачів всередині самого тесту. За це отримав подяку від програмістів: коли починали писати паджинатор для сторінок адмінки, у базі вже були тисячі тестових користувачів.

Для перевірки результату після кожного запиту йде довга низка assertions. Вона перевіряє вірність прийшли даних: http коди відповідей, повідомлення.

Я відключив усі графіки і звіти, крім simple tree view для налагодження. Всі баги можна буде подивитися прямо в Jenkins, а для навантажувального тестування зручніше було заливати відразу на LoadSophia з їх фірмовим плагіном і забирати вже там.

Ось як няшно для програміста виглядає повідомлення про те, чому не пройшла чергова збірка:
image

І більш детально. Чекали 400 код — повернувся 404:
image

Підсумок цього чернокнижия і мракобісся:

З 1200 годин, закладених на розробку, в сумі на написання і актуальне підтримання автотестів пішло 50 годин. На виправлення багів — 70 годин. Причому близько половини з них була пов'язана з нерозумінням замовника та розробників. Результат дуже хороший. Альтернатива перевіряти все вручну відняла б чи не більше часу, ніж пішло б на програмування. Програмісти бачили відразу, як щось йде не так, у всій системі при кожній новій збірці.
В моє відсутність проблем з запуском і зміною автотестів не було як у програмістів, так і у тестувальників. Іноді тести міняли прямо в блокноті, оскільки *.jmx — це теж XML.

Для проведення навантажувального тестування я просто вимикав непотрібні тести на час, обчислюючи, де слабкі місця системи, які тести проходять повільно. Не виникало жодних проблем з використанням нових булочок JMeter. Всі документовано і все зрозуміло.

З труднощів, з якими зіткнувся:

  • Плагін для JMeter, що реалізує oAuth авторизацію, сильно застарів і не працює з oAuth 2.0. Невелику частину функціоналу, пов'язану з авторизацією через соціальні мережі, тестувати доводилося окремо.
  • Підв'язувати Selenium до JMeter — теж сумнівне задоволення. UI Адмінки тестувалося також окремо.
  • Для людей, не стикалися з інтерфейсом JMeter, перше знайомство закінчується відшаруванням сітківки легким розладом.
p.s. Невеликий ліричний відступ. одній з недавніх статей говорилося про спосіб скоротити роботу тестувальника через декомпозицію і, що більш важливо, про проблеми ринку тестування. Однією з відповідей на ринку «замкнуте коло тестувальників», описуваному в початку статті, є стандартизація навичок тестування. З нею роботодавець стане більш впевнений, що знайде на ринку необхідного фахівця, здатного вирішити проблему. Тестувальник ж буде знати, що з отриманими знаннями він не загубиться на ринку. В даному випадку зробити функціональне тестування через JMeter — зовсім не академичное рішення. Але воно зменшило часові витрати і півкіло нервів при аналогічному результаті. У мене був знайомий, який знає лише самий елементарний базис JMeter і Selenium, але був узятий з розпростертими обіймами в одну дуже поважну фірму. Ні на одному співбесіді в житті мене не питали, чи знаю я якусь рідко використовувану бібліотеку. Запитували в основному знову ж таки про JMeter, Selenium (і на чому я пишу для цих рішень). Підхід «головне, знай добре кілька найголовніших інструментів і вмій застосувати» помітно полегшує життя і тестировщику, і роботодавцю, і ринку в цілому.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.