Test Lead в Infopulse
  • Performance of Performance Testing tools

    Респект! (ще одне словечко з мого жаргону)
    Витратив деякий час за збір пруфів, але не жалкую — дізнався щось нове і через кілька днів напишу ще одну статтю, а вам дякую за ідею. А зараз детально:

    — Для того, чтобы судить о производительности нагрузочного инструмента вы должны получить 100% утилизацию ресурсов (желательно CPU) на машине с которой вы подаете нагрузку и не уперется в 100% утилизации ресурсов на машине на которой находится ваш SUT, причем в случает SUT 100% утилизации не должно быть ни по одному из ресурсов — ни CPU, ни RAM, ни IO (в том числе и Network)

    Тут знов питання до вас — чому?
    Гарний приклад: при тестуванні завантаження ми відсікаємо від результатів ramp up та tear down time (а ще 5% та 95% -тилі), тому що результати будуть точніші.

    Ваш приклад: треба отримати утилізацію 100% клієнта та не отримати 100% на сервері, тому що [брак аргументів]. Як це впливає? Я вам допоможу відповісти. Ранком прогнав 3 тести в JMeter по 6 хв, ramp — 2хв, 10к юзерів:
    1) Як і попередні — python flask
    2) nginx — офіційний docker image
    3) не існуюча IP адреса в моїй мережі

    Потім відсік від метрик ramp up та tear down time

    І отримав, що в усіх 3-х тестах однакове використання ресурсів клієнта по CPU та RAM!
    А докер контейнери в під час тесту показували навантаження до 20% CPU.
    А мережевий інтерфейс серверу показав 0 помилок.
    Звісно, RPS у всіх трьох випадках різний (чекайте пост, там бімба)

    Висновок: говорити — не мішки ворочати. А в мене ще й пруфи є.

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

    Я й не претендую на пальму першості. Різні цільові системи покажуть різні результати (у мене різниця між flask та nginx static майже в 10 разів)
    Але знову ж таки, як бачимо, на результат це не впливає. А виб теж могли додати пруфи

    Что бы вы не думали, но я внимательно прочел статью и самого первого комментария говорю о TCP/IP стеке на стороне NAS. А проблемы с ним могут быть следующие — CPU просто не справляется с количеством соединений или это количество ограничено специально, что делается намеренно на практически любом NAS, потому как его задача шарить файлы, а не генерировать максимальное количество Hello World’ов в секунду

    0 помилок кажуть, що все ок

    Для того чтобы понять, что происходит с I/O вам и нужен LA == load average

    дякую за розшифровку

    — Все пункты выше прекрасно пояснют, почему в вашем тесте нельзя игнорировать SUT

    як бачимо — ніт

    — Лирическое отступление: ваш Celeron — переименованый Atom

    ваша правда. Тепер не зможу любити його так само, як раніше

    — Утверждение о том, что ваш сервер может выдержать ~500 RPS следует из... ничего. Но вы уверенно берете это утверждение за основу для следующего теста

    чистий тес показав 520 — попередній раз я майже вгадав

    — Что касается «Expected result — HTTP 200 OK», то да, я серьезно. Ни одного assert’а в ваших скриптах нет, упоминания об анализе логов постфактум тоже нет, вы уверены, что любой другой HTTP код отразится на Success Rate? Еще вопрос для «подумать», а вы уверены, что все тысячи запросов вернули «Hello World»?

    by default тули для перформанс тестування оброблюють коди < 400 як ок.
    Пруфи: docs.locust.io/...​d-successful-or-a-failure
    gatling.io/...​s/current/http/http_check

    І якщо не треба додаткові перевірки, assert’и можна не писати. Кажу це як людина, що практикує performance testing тому, хто очевидно тільки читав по нього

    — Относительно Ramp Up Time. Я понимаю, что охота пуще неволи, но создание новых виртуальных пользователей очень дорогая операция и она влияет на потребление ресурсов на машине с которой подается нагрузка, а соответственно и на то, какую нагрузку этот инструмент может сгенерировать. И, главное, сами же говорите, что Locust не справился с этой задачей, но все равно сравниваете яблоки с апельсинами.
    — Включать Ram up и Teardown в результаты замеров максимальной производительности неверно. Причин тому множество, подумайте хотя бы над тем, сколько стоит создание дополнительного VU для каждого из инструментов

    як я вже писав раніше — метрики клієнта в статті написані без урахування Ram up та Teardown. А ви кажете, уважно читали

    Если написанное выше все еще осталось непонятным, то вы можете смело записать меня в «слившихся», т.к. я не вижу смысла в дальнейших пояснениях. Ну а пока ваша статья, как и ваш доклад не имеют ничего общего с заголовком. Более правильный заголовок: «Я написал три случайных скрипта для трех случайных инструментов, и вот что из этого получилось».

    Ні, мені з вами цікаво — коментуйте ще. А що до заголовка — він точний і у мене є докази. Я можу зробити ще більше тестів, якщо вже існуючих доказів недостатньо.

    Не мішки ворочати...

    Почему же? Я, например, не хожу туда после того, как попал на доклад, где очень титулованый QA рассказывал, что веб сервисы пишутся на XML (это он про SOAP, если что) и о том, как они это XML чудо тестируют. А вы ж поймите, я же деньги за это заплатил. Вот приду туда, а там веб сервисы на XML, или замеры нагрузочного рандома или калькулятор опять тестируют, и при этом докладчик не склонен ни к критике, ни к анализу. Вот что мне там делать? Так что я только рад, и вы не жалейте :)

    Ліричний відступ — оскільки контексту мало, важко зрозуміти, хто тут Д’артан’ян. Маю 2 припущення:
    1) Доповідач все розказував як міг, але не знав загальновживаної термінології (таке іноді трапляється навіть з титулованими). «веб сервисы пишутся на XML» == WSDL?
    2) Він з колегами зробив з костилів велосипед — таке буває частіше ніж хотілося б. Всі їейтять велосипеди аж поки не починають працювати в такому проекті і тоді знаходять відмазки «ну в мене це інше», «в нас вибору не було». І хоча я на конфаг більше люблю доповіді про soft-скіли, такі доповіді теж цікаві саме тим, що наглядно показують, що буде, якщо не робити правильно і до яких проблем це приведе.

    Аналогія: можна вчити ПДД і як водити машину правильно, а можна показати відео з серйозного ДТП, де кров, кишки і частини тіл — дієва демонстрація, нащо все робити за правилами, паттернами та за методологією

    Поддержал: Igor Shevchenko
  • Performance of Performance Testing tools

    так, в офіційних гайдах до всіх тулів є рекомендація виконувати тести в Linux. Але, як то часто буває, користуємось тим, що маємо. І Windows поводить себе в тестах не так і погано, а для невеликих навантажень ви навіть різниці не побачите

  • Performance of Performance Testing tools

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

    Пост — хороший пример того, что нагрузочным тестированием (впрочем, как и любым другим) должны заниматься люди, которые понимают, что они делают. Что тестировал автор, зачем, о чем выводы?

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

    в очередной раз напомнили почему не стоит ходить на QA конференции

    прикро

    Поддержал: Женя Оноприенко
  • Performance of Performance Testing tools

    На стороне NAS TCP/IP стека нет?

    Я не розумію питання. Точніше, відповідь на нього — так, є. І що далі? Спочатку мова було про стек клієнта. Тепер про стек NAS. Попереджуючи наступне питання — в мене між ними в мережі ще й роутер є. Визначтесь, що саме вас цікавить.
    Якщо ваше питання — натяк на те, що перформанс сервера може впиратись в його TCP/IP стек — може й так. Якби мета тесту була заміряти його перформанс (що не так) і проаналізувати ботл неки — тоді це б мало більше значення. Повторюсь — мета тестів написана вище

    Это совсем не праздное любопытство. Если CPU/RAM/IO на стороне сервера уперлись в 100%, то тестируете вы, что угодно, но не производительность нагрузочного инструмента.

    без аргументації це ствердження нічого не варте. Крім того, як я писав вище, 100% не досяг

    Теперь о процентах. А что они вам показывают? В вашем процессоре 4 ядра, ваше Python приложение работает в одном потоке, в итоге при загрузке CPU в 25% ваши тесты становятся совершенно нерепрезентативными

    Не фокусував увагу на цьому окремо (просто написав docker файл) — python додаток крутиться за допомоги gunicorn в 4 worker’и (4 unix процеси) і може використовувати всі 4 ядра. І доречі, не пам’ятаю, чи писав раніше, що поведінка серверу для всіх тестів є константою?

    Но опять же, не одними процентами... курите и LA параллельно.

    Розшифруйте LA, будь-ласка. Бо я взагалі більше за бухати, ніж курити... (додав наприкінці три точки, щоб здаватись загадковішим)

    Теперь о SUT. Зачем для тестирования raw производительности инструментов вам нужно какое-то мифическое приложение? Чем не угодил nginx и статический файл? Вот в такой конфигурации замучаетесь его убивать любым инструментом, даже на вашем полумертвом атоме (хотя это не точно, атом такой атом)

    Бо так захотів — мені, як мінімум, весело було. І чому міфічне? Всі сорси є — качай, збирай. А в чому проблема? Частіше проводжу тестування саме додатків, а не статичних файлів. Ну і головне що? — однакова поведінка у всіх тестах
    А ще в мене не атом, а гордий Celeron :D Ви точно уважно читали статтю?

    Теперь расскажите, как при среднем времени ответа в 10,5 секунд и 533 RPS вы получили 114к запросов за 3 минуты?

    Не бачу, в чому проблема — я навіть відео з пруфами записав. Ви не плутаєте throughput із bandwidth?

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

    причини, вказані вище, визивають великі сумніви :)
    О, я думав, ви тролите з першого комента, типу «не читав, але засуджую». А ви то серйозно...

    Expected result — HTTP 200 OK
    Как это проверялось?

    Ви серйозно?

    Ramp time — 20 sec
    Почему так мало?

    Бо я лінивий і нетерплячий? Чи може проводив довші тести і отримав приблизно ті самі результати (за виключенням кількості реквестів)? Чи може загадковий...

    Отброшены ли из средних и медиан данные из рампапа? Что насчет тиардауна, после 3х минут просто все убивалось или дожидались окончания всех запросов? Результаты тиардауна отброшены?

    Для RPS — ніт. Так, це не правльно, але мета була інша (прям дежавю). Для ресурсів клієнта — так. Після завершення все вбивалось.

    Как, вообще, такой вывод получился? Не вижу ничего, что на него бы указывало.

    Приблизно.Не ставив мету точних вимірів цього параметру.
    Якщо вас цікавлять точні характеристики — підписуйтесь наш телеграм канал та друзів приводьте — зроблю окремий пост, все чітко протестую та поділюсь ;)

    Поддержал: Женя Оноприенко
  • Performance of Performance Testing tools

    Теж стало цікаво. Перевірю пізніше і напишу

    Поддержал: Symonenko Volodymyr
  • Performance of Performance Testing tools

    Дякую за критику. Люблю коли вона констуктивна — тоді вчусь чомусь новому. Саме тому ми всі тут :)
    Тепер до суті

    откуда взялся такой странный Success Rate?

    власне, мене це теж бентежило — і перші тести показували поганий результат для всіх тулів. Пошуки в інеті вказують, що для декстопних ОС часто за замовчанням доступно 1024 відкриті одночасні мережеві з’єднання. І помилки тули видавали відповідні, типу connection cannot be created.
    Саме тому в передумовах тесту я роблю зміни в реєстрі, відкриваючи 65к з’єднань (впевнений ліміт є не просто так і мінуси в його збільшенні теж є, але поки не знайшов)
    Всі тули після правки реєстру показують в результатах єдину помилку — connection timeout.
    Тому на 99% впевнений, що не тестую TCP/IP стек.
    Що ж до Success Rate — я думаю, різниця дійсно в http-клієнтах та підходах до навантаження різних тулів. Саме про це стаття — варто знати, який тул що може.

    Как можно делать какие-либо выводы о производительности инструмента игнорируя потребление ресурсов на стороне SUT — загадка загадочная?

    Мета була інша — перевірити поведінку тулів, а не тестувати продуктивність SUT, про що чесно написано напочатку. Тому і метрики SUT тут будуть не доречні — тестили інше. І якщо поведінка SUT — константа для всіх тулів і тестів, чи не все рівно? Якщо вам просто цікаво — відмітки у 100% CPU та RAM на сервері я не досяг.

    Или Test #2. Среднее вдвое выше, чем в Test #1 не наводит ни на какие мысли?

    Test #2 (Jmeter) 0,5 sec < Test #1 (Jmeter) 15.6 sec
    Перепрошую що ввів в оману, для результатів другого тесту змінив одиниці виміру, оскільки величини менші.

    В целом, вопросы здесь к каждой строчке

    Не соромтесь, задавайте ;) Я на карантині здичавів, залюбки з кимось подискутую. Взагалі, може го дебати по перформанс тестуванню влаштуємо?

    а читателю этот пост, в лучшем случае, ни чем не поможет, а скорее навредит.

    тільки неуважному ;)

    Поддержал: Webfeya Остапова
  • Performance of Performance Testing tools

    Не планировали расширить тест фреймворки, скажем, Siege, Artillery,
    Hey, Yandex Tank?

    так, в планах було

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

    холіварна буде тема. я навіть починав — часу на все не вистачає

    Поддержал: Iegor Timukhin
  • Performance of Performance Testing tools

    для серверу — benchmark, оскільки очікувань не було. Але головна мета була подивитись за поведінкою самих тулів

    rampUsersPerSec вместо rampUsers

    дякую, я спробую

  • Performance of Performance Testing tools

    я й не писав, що він гірший. знаю людей, які ним користуються. І по споживанню ресурсів він показує себе краще JMeter. Але мені, суб’єктивно, він не подобається

  • Performance of Performance Testing tools

    в таблицях середній результат за всі прогони ? чи якоїсь однієї ?

    за 2й. На першому зібрав початкові дані. На другому записував відео, 3й був контрольний. Оскільки різниця була незначна, не вираховував середнє значення

    можливо, ще метрики по різнову оцінюються

    ще минулого року, коли порівнював, помітив, що Gatling та JMeter по різному враховують Connection timeout. Склалось враження, що Gatling їх не враховує в середнє значення відповіді, а JMeter враховує як максимальний час відповіді.До речі, теж цікава тема для дослідження

    Поддержал: Oleg Zarevych
  • Performance of Performance Testing tools

    среднее время отклика для hello world

    якщо мова про перший тест — 10 секунд, мені здається, гарний результат, за умови докера і не дуже потужного серверу.
    В результатах другого тесту допустив помилки з величинами, вже виправив, дякую за уважність!

  • Performance of Performance Testing tools

    я теж в першу чергу підозрював енв, але в такому випадку я мав бі різні результати навіть для одного і того самого тула, але результати ідентичні. Для цього дослідення я проганяв всі тести по 3 рази, для попереднього ще більше.
    Моя думка — результати залежать від реалізації http клієнту та багатопоточності. Теж цікаво, як ці результати будуть корелювати з реальним використанням.
    Можна спробувати провести distributed тест, що менше навантажить клієнти і має показати більш чистий результат

    Поддержал: Oleg Zarevych
  • Telegram бот на Google Apps Script

    трохи пізніше напишу

  • Telegram бот на Google Apps Script

    так, трошки полінувався,думав, наочніше вийде і розбивати не став. Більш того, в мне doPost як раз на 1 скрін. Я думав, комент вище був про логіку...

    Поддержал: Evgeniy Gribkov
  • Telegram бот на Google Apps Script

    дякую, пофіксив

  • Telegram бот на Google Apps Script

    як покращити?

  • Знайомтесь, TestOps!

    і ще про впровадження термінів — отримав листа про QA Fest 2020 — один з актуальних напрямків -Test Automation & TestOps. Ми з колегами саме на це й розраховували — щоб про тест опс почали говорити і всією спільнотою ділитись кращими практиками

  • Знайомтесь, TestOps!

    Ох, дякую за розгорнутий коментар, намагатимусь дати короткі відповіді!

    DevOPS — це дійсно методологія, навіть «культура». Цей термін з’явився не просто так. А щоб принести щось нове в старе. Він НЕ з’явився щоб дати назву адмінам які почали налаштовувати частину інфраструктури для девів.

    так і ми пишемо не про те, що якщо тестера вкусить радіоактивний девопс, той стане тестопсом — а про розширення фокусу: кращу взаємодію людей для досягнення результату, надання більшої уваги нефункціональним тестам — бути дійсно QA а не QC

    Виявилось що взаємодія між командою розробки та командою оперейшенс стала ще більш важливою, назбирались шаблони й кращі практики в цьому контексті. Так і виникла саме методологія нова і дали їй назву DevOps.
    А от навіщо вводити TestOps поки не зовсім ясно...

    Можливо дивлюсь суб’єктивно, бо цікавлюсь цим напрямком — зараз кожна 3 тема доповіді на конференціях і статті на технічних сайтах — як проводити тестування мікросервісів — власне ті самі кращі практики ;) Багато хто вже робить тестопс, просто його ЩЕ так не називає

    Ще раз, у слові DevOps — dev — це команда розробки, а не програмісти. Вже давно у світі еджайлу — тестери є частиною команди розробки. Скрізь де по серйозному впроваджують девопс — дуже близько говорять про автоматизацію, про тестування, про роботу з вимогами. Це комплексний підхід. В DevOPS вже і доволі давно входить набір практик і шаблонів, які вже включають і тестерів, і бізнес-аналітиків/продакт-овнерів, і девів. Нічого не змінилось, це все передбачено, і описано.

    В коментарях вище вже писали, що DEV включає в себе все, від аналізу до SEO, з чим я не згоден — команда може бути супер гнучкою, але аналітики краще аналізують, тестери — тестують, розробники — розроблюють, менеджери — менеджать.
    І девопс, за визначенням, все ж таки в першу чергу саме про розробку і експлуатацію, все інше є плюсом, але за кадром.

    Прийшов Agile, почав говорити про відповідальність за якість всією командою, про QA практики ... Ніхто цього не зрозумів, нічого не змінилось. Але наших тестерів які й далі продовжували займатись суто QC — почали тепер називати QA Engineer.
    Далі прийшов DevOps. Те ж саме... Взяли адмінів, яких вже були припахали дженкінси-пере-дженкінси налаштовувати й перейменували їх в DevOps. Без розуміння що воно таке. Без розуміння того, що це взагалі було про підходи, про колаборацію, а не про нову роль.

    Та сама біль — кожен перший IT-спеціаліст стверджує, що практикує скрам, хоча насправді робить карго-культ.
    Але те, що не всі правильно використовують методології та терміни не означає, що не треба впроваджувати нічого нового

    То може так само давайте і новий термін введемо для тестеро-автоматизаторів-адмінів? А може ще давайте девелоперів які, обоги, поки ніхто не чує — «пишуть авто тести» — почнему називати TestDev-ами? хм... чи може краще DevTest-ами? як краще звучить? :)

    SDET. Все вже придумали до нас

    Те що науково технічний прогрес росте, і інструменти стали потужніші, але й складніші, і тепер оперейшенсам чи адмінам — треба трохи більш впахувати — хіба заслуговує на нову назву? Може давайте роботу робити, а не вигадувати 100500 термінів, яку більшість все одно не розуміє і перекручує як з тим же DevOps. Як з QA:)

    Ми в статті говорили про тест опс не як про роль — а як про підхід.
    Але навіть назва ролі має переваги — коли ви читаєте резюме, і бачиш там розробник, спитаєш, на чому пишеш, які технології знаєш? Бачиш ДевОпс — і розуміш, що людина вміє умовний дженкінс налаштувати і код написати. Тобто для кожної ролі в нас вже є сформований стереотипний список очікувань.

    А то у нас люблять на себе погонів навішати

    Дійсно так. Теж не люблю, коли підпис в пошті в 4 рази більший за повідомлення. Але багато хто робить і любить — головне, щоб всі були задоволені

    Треба «контролювати якість? — тобто по факту коли щось зроблене, перевірити чи воно відповідає поставленим наперед вимогам (верифікація) чи адекватним потребам його користувачів (валідація)» — і не важливо де це робиться, на якій стадії. Для цього вже давно є термін — QC, Testing. У всіх класичних підручниках написано, що тестування застосовується до всіх стадій починаючи з формування вимог.

    дякую, кеп! підручники я теж читав. Не зрозумів, до чого саме ця критика. Тому прошу додаткового роз’яснення

    Хто зна, може і є сенс в нових ролях... Нових термінах. От лиш мені здається, що нам би розібратись з тими термінами що вже є:) Навчитись всім гуртом відповідати за якість. Думати перед тим як починати щось робити, а не після.

    Так ми ж з цього почали! Я написав, що є, а ти мені опонував! Будь послідовнішим! Я бачу, що IT розвивається швидко, поки будеш розбиратись з термінами, що є, вони застаріють (десь у віддалені чую, як плачуть спеціалісти з блокчейну)
    Гуртом відповідати про якість — так і я про це. і DevOps, і TestOps, і Agile і навіть здоровий глузд

    Взявши впроваджувати певну методологію типу DevOps — розібратись в деталях що воно таке в повному обсязі, комплексно.

    Сам я не впроваджу. І ти. Ніхто з читачів сам не зробить. Тому варто почати — якщо спільноті тема сподобається, разом ми сформуємо тестопс методологію

    На мою думку, зараз же з’являється «нова планка» більше через те що народ масово не розуміє ні що таке QA ні що таке Agile ні що таке DevOps. А ще не має досвіду як це все впроваджувати. І виникають тренди масового однакового непорозуміння) На таке меми треба нові вводити, а не терміни/ролі.

    повторюсь — від того, що частина IT-спільноти (впевнений, менша) не розуміє, навіщо потрібні методології, не означає, що не варто про них говорити. Бо дійсно виходить мем — не жили добре, не варто я починати.

  • Знайомтесь, TestOps!

    автори ISTQB хоча б коли небудь лізли до питань інфраструктури

    ви про книжки чи сертифікацію? не вивчав питання, але припускаю, що хоч хтось з авторів книжок міг написати що небудь і на цю тему
    ISTQB — корисна штука для кожного тестера, оскільки стандартизує термінологію та підходи.
    Іноді зустрічаю тих, хто теорію не вчив, бо практик, а потім не може 2 теста написати

  • Знайомтесь, TestOps!

    ти впроваджуєш зміни

    Я ж про це і писав ;)

← Сtrl 1234 Ctrl →