Виконання стрес-тесту на веб-додатку?

У минулому я використовував інструмент напруги для веб-застосувань та пілот Microsoft для стрес-тестування веб-додатків. Я написав просту домашню сторінку, скрипт для входу та посібник із сайту (на веб-сайті електронної комерції, додавши кілька предметів у кошик та замовлення).

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

URL-адресою інструментів, які я використовував, були Microsoft Homer (він же, інструмент напруги веб-додатків Microsoft ) та Pylot .

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

Що ви зробили, якими інструментами користуєтесь та який успіх у своєму підході? Найцікавіша для мене частина - це якась змістовна формула для обчислення кількості одночасних користувачів, яку додаток може підтримувати з числа, про які повідомляє програма стрес-тесту.

Ось ще один голос за JMeter .

JMeter - це інструмент тестування навантаження з відкритим кодом, написаний на Java. Він здатний протестувати ряд різних типів серверів (наприклад, веб, веб-сервіси, база даних, майже все, що в основному використовує запити).

Однак у вас є крута крива навчання, коли ви починаєте складні тести, але це того варте того. Ви можете встати і працювати дуже швидко, і в залежності від того, який стрес-тест ви хочете зробити, це може бути добре.

Плюси:

• Відкритий / безкоштовний інструмент від проекту Apache (допомагає при покупці)
• Легко розпочати роботу та простий у використанні, коли ви зрозумієте основні поняття. (Тобто, як створити запит, як створити твердження, як працювати зі змінними тощо).
• Дуже масштабований. Я провів випробування з 11 машинами, що генерують навантаження на сервер, на межі майже мільйон хітів / годину. Це було набагато простіше в налаштуванні, ніж я очікував.
• Має активну спільноту та хороші ресурси, які допоможуть вам встати та працювати. Спочатку прочитайте підручники і пограйте з ним деякий час.

Мінуси:

• Інтерфейс написаний Swing. (Тьфу!)
• JMeter працює шляхом аналізу тексту відповіді, поверненого сервером. Тож якщо ви хочете перевірити будь-яку поведінку JavaScript, вам не пощастить.
• Крива навчання крута для непрограмістів. Якщо ви знайомі з регулярними виразами, ви вже випереджаєте гру.
• На форумі підтримки є велика кількість ( вставних експлікативних ) ідіотів, які задають дурні питання, які можна було б легко вирішити, якби вони дали документації навіть короткий погляд. ("Як я використовую JMeter для стрес-тестування мого інтерфейсу Windows", з'являється досить часто).
• Повідомлення "поза межами" залишає бажати кращого, особливо для великих тестів. У тесті, про який я згадував вище, мені довелося написати програму для швидкої консолі, щоб виконати деякі з "xml-logfile" до "html" перетворень. Це було кілька років тому, тому, ймовірно, цього більше не потрібно.

Я використовував Grinder . Це відкритий код, досить простий у використанні та дуже налаштований. Він заснований на Java і використовує Jython для сценаріїв. Ми пов'язували це з веб-додатком .NET, тому не думайте, що це лише інструмент Java (за своєю природою будь-який інструмент веб-стресу не повинен бути прив’язаний до платформи, яку він використовує).

Ми зробили деякі акуратні речі з цим ... ми були веб-додатком для телекомунікацій, тому одним із цікавих способів використання, яке я створив, було наслідування набору номера за допомогою нашого веб-додатку, а потім застосовано інструмент для автоматичного відповіді, який у нас був (в основному це був підручник. додаток від Майкрософт для підключення до їх сервера RTC LCS ... саме до цього підключається Microsoft Office Communicator у локальній мережі ... потім модифікується для того, щоб автоматично приймати виклики). Тоді це дозволило нам використовувати це замість дорогого інструменту телефонії під назвою Молоток (або щось подібне).

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

Я настійно рекомендую цей інструмент, дуже корисний для ціни ... але сподіваюся зробити з ним певні налаштування (у нього є вбудований проксі для запису сценарію, але він може знадобитися налаштування для зйомки чогось типу сеансів ... Я знаю Мені довелося налаштувати його, щоб використовувати унікальний сеанс на потік).

Трохи запізнюємось на цю вечірку. Я погоджуюсь, що Pylot - це найкращий інструмент з відкритим кодом, що надходить, і що надходить. Він простий у використанні і над ним активно працює чудовий хлопець ( Корі Голдберг ). Як засновник OpenQA , я також радий, що Пілот зараз розміщений на нашій домашній сторінці та використовує частину нашої інфраструктури (а саме форумів).

Однак я також нещодавно вирішив, що вся концепція тестування навантаження виявилася помилкою: емуляція HTTP-трафіку з такими складними, як вони стали, є болем у задниках. Тому я створив комерційний інструмент BrowserMob. Це зовнішня послуга тестування навантаження, яка використовує Selenium для контролю реальних веб-браузерів під час відтворення завантаження.

Цей підхід, очевидно, вимагає на тону більше обладнання, ніж звичайні методи перевірки навантаження, але апаратне забезпечення насправді досить дешеве, коли ви використовуєте хмарні обчислення. І приємним побічним ефектом цього є те, що сценарій набагато простіше, ніж звичайне тестування навантаження. Для вилучення файлів cookie, стану сеансу .NET, параметрів запиту Ajax і т. Д. Вам не потрібно робити будь-якого розширеного узгодження регексу (як вимагає JMeter). Оскільки ви користуєтесь реальними браузерами, вони просто роблять те, що повинні робити.

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

Я використовував JMeter . Окрім тестування веб-сервера, ви також можете протестувати сервер бази даних, сервіси обміну повідомленнями та сервери електронної пошти.

аби , облога , цзун , httperf , Пробивний , Pylot, запит лог-аналізатор , perftools

Для простого використання я пропоную ab (тест апачу) і облогу, пізніше це потрібно, оскільки ab не підтримує файли cookie і створить нескінченні сесії з динамічного сайту.

обидва прості для початку:

ab -c n -t 30 url

siege -b -c n -t 30s url

облога може працювати з більшою кількістю URL-адрес.

остання версія облоги вмикає багатослівний в siegerc, що дратує. ви можете відключити його лише відредагувавши цей файл ( /usr/local/etc/siegerc).

Для веб-сервісу ознайомтеся з loader.io .

Підсумок:

loader.io - безкоштовна послуга тестування навантаження, яка дозволяє провести стрес-тест на веб-додатки / apis з тисячами одночасних підключень.

Вони також мають API .

Оскільки це питання все ще залишається відкритим, я також міг би зважити на це.

Хороша новина полягає в тому, що за останні 5 або більше років інструменти з відкритим кодом дійсно дозріли і вилетіли в космос, погані новини - там їх так багато.

Ось мої думки: -

Jmeter vs Grinder

Jmeter керується специфікацією стилю XML, побудованою за допомогою GUI.

Grinder використовує сценарії Jython в муті-потоці Java, тому більше орієнтований на програмістів.

Обидва інструменти оброблятимуть HTTP та HTTPS та матимуть проксі-рекордер для початку роботи. Обидва інструменти використовують модель Controller для управління кількома тестовими агентами, тому масштабованість не є проблемою (з урахуванням доступу до хмари).

Який краще:-

Жорсткий виклик, оскільки крива навчання є крутим з обома інструментами, коли ви потрапляєте у складніші сценарії вимог до переписування, кореляції URL-адрес, надання унікальних даних для Віртуального користувача та моделювання першого разу або повернення користувачів (шляхом маніпулювання заголовками HTTP).

Це говорить про те, що я розпочну з Jmeter, оскільки цей інструмент має величезну кількість наступних, і в Інтернеті є багато прикладів та навчальних посібників для використання цього інструменту. Якщо і коли ви стикаєтеся з "дорожньою блокою", це те, що ви не можете "легко" зробити з Jmeter, тоді подивіться на Grinder. Хороша новина в тому, що обидва ці інструменти мають однакові вимоги до Java, а рішення "суміш і узгодження" не викликає сумніву.

Щось нове, що можна додати - браузери без голови, у яких запущено кілька екземплярів Selenium WebDriver.

Це порівняно новий підхід, оскільки він покладається на доступність ресурсів, які зараз можна забезпечити з Хмари. При такому підході сценарій Selenium (WebDriver) береться і запускається в безголовий браузер (тобто WebDriver = новий драйвер HtmlUnitDriver ()) у декількох потоках.

З досвіду з Amazon M1 Small Instance можна виконати близько 25 екземплярів "безголових браузерів".

Це означає, що всі кореляції, проблеми перезапису URL-адрес зникають, коли ви перестановлюєте свої функціональні сценарії тестування на сценарії тестування продуктивності.

Масштабованість знижується, оскільки для управління навантаженням знадобиться більше VM, порівняно з драйвером HTTP, таким як Grinder або Jmeter. Це означає, що якщо ви хочете задіяти 500 віртуальних користувачів, то за допомогою 20 маленьких екземплярів Amazon (6 центів на годину кожен) вартістю всього 1,20 долара на годину ви отримуєте навантаження, що дуже близьке до реального досвіду користувачів.

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

Нещодавно ми почали використовувати Gatling для тестування навантаження. Настійно рекомендую спробувати цей інструмент для тестування навантаження. Ми використовували SOASTA та JMETER у минулому. Наша основна причина вважати Гетлінга наступна:

• Диктофон для запису сценарію
• Використання Akka та Netty, що дає кращі показники продуктивності порівняно з моделлю Jmeter Threading
• DSL Scala, який є дуже ретельним у порівнянні з Jmeter XML
• Легко писати тести, не лякайтеся, якщо це скала.
• Звітність

Дозвольте навести простий приклад написання коду за допомогою коду Гетлінга:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

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

Ось декілька посилань: Навчальний посібник з
Gatling
Gatling

Нещодавно я говорив про це, ви можете продовжити розмову тут:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

Це старе питання, але я вважаю, що новіші рішення заслуговують на згадку. Оформити замовлення LoadImpact: http://www.loadimpact.com .

Я спробував WebLoad - це досить акуратний інструмент. Він поставляється з тестовим IDE-скриптом, який дозволяє записувати дії користувачів на веб-сайті. Він також малює графік під час виконання стрес-тесту на вашому веб-сервері. Спробуйте, настійно рекомендую.

Спробувавши все, що було сказано тут, я вважав, що навантажувач curl є найкращим для моїх цілей. дуже простий інтерфейс, моніторинг у реальному часі, корисна статистика, з якої я будую графіки продуктивності. Всі функції libcurl включені.

Блейз-метр має хромоване розширення для запису сеансів та експорту їх у JMeter (наразі потрібен логін). Ви також маєте можливість заплатити їм гроші, щоб запустити їх на своєму кластері серверів JMeter (їх ціна здається набагато кращою, ніж LoadImpact, який я щойно перестав використовувати):

• Розширення BlazeMeter Chrome
• Запис у блозі про це

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

Ви задали це питання майже рік тому, і я не знаю, чи все ще шукаєте інший спосіб порівняльного аналізу вашого веб-сайту. Однак оскільки це питання все ще не позначено як вирішене, я хотів би запропонувати безкоштовну веб-службу LoadImpact (btw. Не пов’язана). Щойно отримав це посилання через twitter і хотів би поділитися цією знахідкою. Вони створюють розумний хороший огляд, і на кілька доларів більше ви отримуєте "режим повного впливу". Це, мабуть, звучить дивно, але удача підштовхує та гальмує вашу службу :)

Я знайшов IBM Page Detailer також цікавим інструментом для роботи.

Я використовував openSTA .

Це дозволяє записати сеанс з веб-сайтом, а потім відтворити через відносно просту мову скрипта.

Ви можете легко протестувати веб-служби та писати власні сценарії.

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

Це відкритий і безкоштовний код.

Він створює ряд звітів, які можна зберегти у електронну таблицю. Потім ми використовуємо зведену таблицю, щоб легко проаналізувати та графікувати результати.

Ми використовуємо згаданий інструмент Microsoft - інструмент напруги веб-додатків Microsoft. Це найпростіший інструмент, який я використав. Він обмежений багатьма способами, включаючи лише можливість потрапляння на порт 80 при створених вручну тестах. Але його простота використання означає, що вона насправді звикає.

Ми доповнюємо навантаження від цього інструменту іншими інструментами, включаючи OpenSTA та павучки для перевірки посилань.

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

Я б запропонував відкрити ще одне запитання щодо інтерпретації результатів інструменту МС.

Тестова версія для Visual Studio 2010 (також хороша 2008 рік). Це дійсно простий та потужний інструмент для створення тестів для веб / завантаження.

Бонус за цей інструмент при використанні проти серверів Windows полягає в тому, що ви отримуєте інтегрований доступ до всіх статистичних даних про сервер perfmon у вашому звіті. Дійсно корисна.

Інший бонус полягає в тому, що за допомогою проекту Visual Studio ви можете інтегрувати "Сеанс продуктивності", який профайлює виконання коду вашого веб-сайту.

Якщо ви обслуговуєте веб-сторінки з сервера Windows, це найкращий інструмент там.

Існує окрема і дорога ліцензія, необхідна для використання декількох машин для завантаження тестової програми.

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

Отже, під час розробки ми включаємо дуже базове багатокористувацьке тестування (з використанням селену), яке перевіряє наявність базових божевільних дій, таких як невдале управління сеансом, очевидні проблеми паралельності та очевидні проблеми з вмістом ресурсів. Нетривіальні проекти включають це в процес безперервної інтеграції, тому ми отримуємо дуже регулярні відгуки.

Для проектів, що не мають екстремальних вимог до продуктивності, ми включаємо в тестування базові показники продуктивності; Зазвичай ми виписуємо тести за допомогою BadBoy та імпортуємо їх у JMeter, замінюючи дані для входу та інші конкретні речі. Потім ми розширюємо їх до рівня, що сервер обробляє 100 запитів в секунду; якщо час реакції менше 1 секунди, зазвичай цього достатньо. Ми запускаємо і продовжуємо своє життя.

Для проектів, що мають надзвичайні вимоги до продуктивності, ми все ще використовуємо BadBoy та JMeter, але вкладаємо багато енергії для розуміння вузьких місць на серверах на нашій тестовій установці (зазвичай, веб-серверах та серверах баз даних). Там добре інструмент для аналізу журналів подій Microsoft який дуже допомагає в цьому. Ми зазвичай знаходимо несподівані вузькі місця, які ми оптимізуємо, якщо можливо; це дає нам програму, яка є максимально швидкою на "1 веб-сервер, 1 сервер баз даних". Потім ми зазвичай розгортаємося до нашої цільової інфраструктури і використовуємо одну з послуг "Дметр у хмарі" для повторного запуску тестів у масштабі.

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

Головне - переконатися, що ви не просто проводите свої стрес-тести, а також збираєте інформацію, необхідну для розуміння ефективності вашої заявки.

Тут багато згаданих хороших інструментів. Цікаво, чи інструменти відповідають на питання: "Як ви стрес-тестуєте веб-додаток?" Інструменти насправді не пропонують метод напруження веб-програми. Ось що я знаю:

Стресове тестування показує, як веб-додаток виходить з ладу, подаючи відповіді на все більшу кількість користувачів. Стресове тестування показує, як функціонує веб-додаток, поки воно не працює. Більшість веб-додатків сьогодні, особливо соціальні / мобільні веб-програми, - це інтеграція сервісів. Наприклад, коли у травні 2011 року в Facebook вийшов з ладу, ви не можете увійти у веб-додаток Pepsi.com. Додаток не вийшов з ладу, лише значна частина його нормальної функції стає недоступною для користувачів.

Тестування продуктивності показує здатність веб-програми підтримувати час відгуку незалежно від того, скільки користувачів одночасно використовують додаток. Наприклад, додаток, який обробляє 10 транзакцій в секунду з 10 одночасними користувачами, повинен обробляти 20 транзакцій в секунду у 20 користувачів. Якщо програма обробляє менше 20 транзакцій в секунду, час реакції збільшується і довше і програма не може досягти лінійної масштабованості.

Також у наведеному вище прикладі підрахунок транзакцій за секунду має бути лише успішними операціями тестового випадку використання / робочого процесу. Збої, як правило, трапляються в більш коротких часових періодах і зроблять вимірювання TPS надто оптимістичним. Невдачі важливі для перевірки на стрес та працездатність, оскільки вони також створюють навантаження на додаток.

Я написав методологію PushToTest у Посібнику користувача TestMaker за адресою http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker випускається у двох варіантах: Версія спільноти з відкритим кодом (GPL) та TestMaker Enterprise (комерційна з великою професійною підтримкою.)

-Франк

Погляньте на LoadBooster ( https://www.loadbooster.com ). Для тестування веб-сайтів використовується веб-переглядач PhantomJS / CasperJs без голови. Phantomjs проаналізує та візуалізує кожну сторінку, виконає сценарій на стороні клієнта. Підхід безголовкового браузера простіше написати тестові сценарії для підтримки складної AJAX важкої програми Web 2.0 navigation навігація в браузері, натискання миші та натискання клавіші на браузер або зачекайте, поки в DOM не існує елемента. LoadBooster також підтримує селенний HTML-скрипт.

Відмова: Я працюю на LoadBooster.

Спробуйте ZebraTester, який набагато простіше у використанні, ніж jMeter. Я використовував jMeter протягом тривалого часу, але загальний час настройки для тесту навантаження завжди був проблемою. Хоча ZebraTester не є відкритим кодом, час, який я заощадив за останні шість місяців, компенсує це. Вони також мають портал SaaS, який можна використовувати для швидкого запуску тестів за допомогою їх генераторів навантаження.

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

Погляньте на TestComplete .

Я друге пропозиція openta. Я просто додам, що це дозволяє робити моніторинг сервера, який ви тестуєте, використовуючи SMTP. Ми слідкуємо за завантаженням процесора, використовуваною пам'яттю, відправленими байдами і т. Д. Єдиним недоліком є ​​те, що якщо ви знайдете щось зашкоджене і хочете виправити, воно покладається на кілька бібліотек з відкритим кодом, які більше не підтримуються, тому отримуємо компіляцію версія джерела більш складна, ніж у більшості ОС.

Я грав з JMeter. Можна подумати, що це неможливо перевірити, це ASP.NET Webforms. Огляд полягав у моїх тестах. Я не розумію, чому, але є кілька інструментів, які не справляються з відомством право. Мій поточний проект - ASP.NET MVC, і JMeter добре працює з ним.

Я мав хороші результати з FunkLoad :

• простий у взаємодії користувачів сценарій
• звіти зрозумілі
• може контролювати завантаження сервера

Загрожуючи звинуваченням у безсоромному саморекламі, я хотів би зазначити, що у своєму прагненні до безкоштовного інструменту тестування навантажень я перейшов до цієї статті: http://www.devcurry.com/2010/07/10-free- інструменти-to-loadstress-test-your.html

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

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

Ось це: http://sourceforge.net/projects/loadmonger

PS: Немає коментарів до снайда від імені людей, які знайомі з міським сленгом. Я не був, але зараз трохи світліший.

Я також голосую за jMeter і хочу додати декілька цитат до відповіді @PeterBernier.

Основне питання, на яке відповідає тестування завантаження, - скільки одночасно користувачів можуть підтримувати мої веб-програми? Щоб отримати правильну відповідь, тестування навантаження має відображати реальне використання додатків якомога ближче .

Майте на увазі вище, jMeter має багато будівельних блоків Логічні контролери , Налаштування елементів , Попередні процесори , Слухачі , ... які можуть допомогти вам у цьому.

Ви можете імітувати реальну ситуацію за допомогою jMeter, наприклад, ви можете:

1. Налаштування Jmeter виступати в якості реального браузера шляхом настройки ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Налаштування JMeter для створення призначених для користувача запитів (визначаючи number of users per second, ramp-up time, scheduling, ...)
3. Налаштуйте безліч клієнтів з jMeter на них, щоб зробити тест на розподілене навантаження.
4. Обробити відповідь, щоб виявити, чи сервер реагує правильно під час тесту. (Наприклад assertвідповідь, щоб знайти текст у ньому)

Зверніть увагу:

• Почати справжній тест веб-додатків із jMeter легко за лічені хвилини. У jMeter є дуже простий інструмент, який записує ваш тестовий сценарій (знаю як HTTP(S) Test Script Recorder).
• jMeter має багато плагінів на http://jmeter-plugins.org .
• Користувальницький інтерфейс jMeter базується на зручностях та вніс добрі зміни в jMeter 3.2. З іншого боку, врахуйте, що графічний інтерфейс JMeter слід використовувати лише для тестування та налагодження. Недоцільно використовувати його в режимі GUI для фактичного тестування. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Налаштуйте і протестуйте свій сценарій та запустіть його в режимі non-gui.
• У програмі jMeter (відомий як listeners) представлено безліч звітів, які показують інструменти, але вони не мають бути використані під час тесту. Ви повинні запустити свій тест і генерувати звіти ( .jtlфайли). Потім ви повинні використовувати ці інструменти для аналізу результатів. Перегляньте https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats або https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

На https://www.blazemeter.com/jmeter є дуже гарна та практична інформація, яка допоможе вам налаштувати тестове середовище.