⭕️Історія: Браузери раніше самостійно вирішували, що і як довго кешувати.
Cache-Control: no-cache, max-age=3600
Це зберігання копій відповідей (у браузері або проміжних серверах), щоб зменшити навантаження на сервер і пришвидшити доступ. Кешування контролюється через Cache-Control, ETag, Expires.
✅️Онлайн-магазин або портал з великою аудиторією
✅️API, яке викликають інші системи
✅️Мобільний або PWA додаток з інтерактивним бекендом
✅️Великий обсяг даних (CRM, аналітика)
✅️Рекламні кампанії чи розпродажі
✔️Має GUI і CLI
✔️Працює з HTTP, WebSocket, FTP, БД, SOAP
✔️Підходить для навантажувального тестування в UI або автоматично
✅Threads (Users): скільки одночасних юзерів (напр. 100)
✅️Threads: 100
✅️Ramp-Up: 60
✅️Loop Count: 10
✅️HTTP Request: GET /api/data
✅️Constant Timer: 100 мс
✅️Assertion: Response code = 200
✅️Start: 50 Threads
✅️Add: 50 кожні 30 сек
✅️Досягти: 1000 Threads
✅️Спостерігайте: Error %, тривалість відповіді, CPU, RAM
✅️Thread Group 1: 100 Threads, Ramp-Up: 60
✅️Thread Group 2: 1000 Threads, Ramp-Up: 5, Start Delay: 120 сек
✅️Threads: 100
✅️Ramp-Up: 60
✅️Loop: Forever
✅️Scheduler: ON → Duration: 28800 сек (8 годин)
✅️Той самий сценарій з Threads: 100, 200, 400
✅️Loop Count: 10
✅️Threads: 10
✅️Ramp-Up: 10
✅️Loop Count: 100
✅️Sampler: JDBC Request або HTTP POST до API
✅️Якщо API — надсилаємо великі payload'и
✅️Якщо БД — запити типу SELECT * FROM orders WHERE date BETWEEN ...
✅️CSV Data Set Config: файл з параметрами для підстановки (напр. айдішники, дати)
✅️Assertion: перевіряємо, що відповідь не порожня / статус = 200
Щоб працювати з різними середовищами (dev/stage/prod), варто використовувати власні базові URL, токени, параметри у вигляді змінних.
{{base_url}}/users замість повної адреси вручну.Postman підтримує JavaScript для автоматизації: можна обчислити токен, згенерувати дату, виконати перевірку.
pm.test("Status code is 200", function () {Запити можна об’єднувати у колекції — за функціональністю або мікросервісом.
Допомагає запускати всі запити з колекції по черзі, з різними наборами даних (CSV/JSON).
Забезпечують запуск запитів за розкладом — щогодини, щодня. Дають змогу виявити збої API після релізу.
Дозволяють симулювати відповіді API, навіть якщо бекенд ще не реалізований.
Відповіді можуть відображатися у вигляді таблиць, графіків — за допомогою шаблонів (HTML + Handlebars).
Інтеграція з CI/CD: запуск тестів через Newman у пайплайнах.
Перевірки статус-кодів, значень у полях, структури JSON тощо.
pm.response.to.have.jsonBody('user.id');😑 Як працюють типи авторизації (Bearer, Basic Auth, API Key)
😑 Як писати умовні конструкції у тестах (if-else на різні відповіді)
😑 Як використовувати глобальні, локальні та середовищні змінні
😑 Як зберігати динамічні значення між запитами (pm.environment.set)
😑 Як організовувати колекції для зручного користування і командної роботи
HTTP-запит (наприклад, GET/products) на домен, пов’язаний з gateway (наприклад, api.mysite.com).HTTPS) розшифровується (термінується) на стороні gateway або load balancer, і далі в системі йде як звичайний HTTP.client_id. Якщо щось не так — повертається 401 або 403.429 Too Many Requests./products перетворити на /api/v1/items) і передати далі в мікросервіс.Якщо CORS налаштовано неправильно, frontend не отримає відповідь навіть при правильному запиті.
😑 Надішли більше запитів, ніж дозволено (наприклад, 11 при ліміті 10/хв)
😑 Перевір 429 статус та повідомлення
😑 Зачекай хвилину — чи обнуляється ліміт?
😑 Різні ролі — різні обмеження?
GET /products запитів протягом хвилини😑 Без токена, з битим або простроченим токеном
😑 401 чи 403 — чи відповідає статус очікуванню?
😑 Перевір дозволи для кожної ролі
GET /orders без токена — очікуємо 401/admin — очікуємо 403/reports, але не до /users😑 Валідні та невалідні URl
😑 Заборонені шляхи для звичайного користувача
GET /api/v1/products → має потрапити до відповідного сервісуGET /api/v1/nonexistent → 404 Not Found/admin/settings → 403😑 Чи зберігається Authorization при редиректах
😑 Чи правильні CORS-заголовки для фронтенду
app.example.com має правильні CORS-заголовкиevil.com → перевірити, що CORS блокує😑 Великі тіла запитів
😑 Довгі URI
😑 Повторний запит з тим самим токеном
POST із тілом 1 МБ JSON → чи обробляється без помилки?GET-запит з 250 символами в URI — чи не обрізається?POST /checkout з однаковим токеном — чи не створює дубль?
Він працює як проксі з логікою, часто використовуючи маршрути, плагіни або фільтри для контролю потоку даних. Це перша точка контакту клієнта з системою, яка може сильно впливати на безпеку, швидкість і стабільність.
❓ Як реалізувати єдину точку входу?
❓ Як захистити внутрішню архітектуру?
❓ Як керувати доступом, логуванням і навантаженням?
🎥 Маршрутизація — розподіл запитів на відповідні сервіси
🎥 Аутентифікація та авторизація — перевірка токенів і прав
🎥 Rate limiting — захист від DDoS і перевищення лімітів
🎥 Кешування — зменшення навантаження на бекенд
🎥 Трансформація даних — зміна формату запитів/відповідей
🎥 Логування і моніторинг — фіксація всієї активності
😑 Один запит на api.mysite.com може всередині бути розподілений між /auth, /products, /orders
😑 Gateway обмежує зовнішні інтеграції лише дозволеними методами
😑 Уся автентифікація зосереджена в одному місці
😑 Внутрішні сервіси ізольовані від зовнішнього світу
💖 Kong — open-source з розвинутим ком’юніті
💖 NGINX — легкий, швидкий, зручний для кастомізації
💖 Amazon API Gateway — хмарне рішення для AWS
💖 Spring Cloud Gateway / Zuul — частина екосистеми Java
😑 Gateway може змінювати поведінку API — це слід враховувати під час тестування
😑 Статуси 403, 429, 502 — часто приходять не від самого API, а від gateway
😑 Rate limiting варто перевіряти з кількома запитами поспіль
😑 Приклад edge-case: зламаний токен, перевищення розміру запиту, повторне надсилання
😑 У проєктах, де авторизація “на gateway”, логіка токенів і ролей тестується саме тут
💢 Одна точка відмови — якщо gateway падає, недоступні всі сервіси.
💢 Помилки в налаштуваннях — можуть заблокувати легальні запити або відкрити доступ тим, кому не слід.
💢 Мішень для атак — gateway першим приймає запити ззовні, тому часто стає ціллю.
💢 Вразливість через застаріле ПЗ — без оновлень можуть з’явитися діри в безпеці.
💢 Відсутність резерву — без запасного плану збій gateway = збій системи.
request flow через Gateway та як правильно перевіряти rate limiting.
😑 Виявити нестійкість у коді
😑 Перевірити обробку помилок (error handling)
😑 Запобігти крашам і втраті даних
😑 Підвищити довіру до продукту: баги часто ховаються саме в edge-case’ах
🔸 Ввести в поле “Телефон” — текст: abcdef
🔸 Вставити у форму emoji або спецсимволи
🔸 Натиснути “Зберегти”, не заповнивши обов’язкові поля
🔸 Ввести занадто довгий текст (500+ символів у полі “Ім’я”)
🔸 Відправити запит без токена авторизації
🔸 Передати userId: null або email: "123"
🔸 Викликати PUT замість POST
403 / 401 / 422 — чи правильно реагує бекенд?🔸 Вимкнути інтернет і натиснути “Оновити”
🔸 Повернути екран під час завантаження
🔸 Кілька разів швидко натиснути на кнопку
🔸 Надати доступ до камери, а потім заборонити
✔️ Подумати: що піде не так?
✔️ Визначити точку входу (UI/API/дія користувача)
✔️ Ввести дані або умову, яка порушує норму
✔️ Передбачити очікувану негативну реакцію
✔️ Перевірити, чи не зламалась система
🔹 Повідомлення про помилки мають бути чіткі й зрозумілі
🔹 Логувати результати — негативне тестування допомагає писати хороші тест-кейси
🔹 Враховувати edge-case’и: null, пусті поля, нестандартні мови, неочікувані типи даних
🔹 Не обмежуватись UI — тестувати також API, базу, мережу
*️⃣Якщо змінити колір кнопки «Купити», CTR зросте.
*️⃣Якщо додати індикатор прогресу в анкеті, більше користувачів її завершать.
*️⃣Якщо замінити модальне вікно на інлайн-повідомлення, конверсія не впаде.
😑Тестувальник помічає: форма реєстрації довга, і часто користувачі не доходять до останнього кроку.
😑Чи коректно працюють варіанти А і B?
😑Чи зібрані події для аналітики?
😑Чи все видно в DevTools / Network / аналітичних подіях?
*️⃣Кнопка «Підтвердити» виглядає неактивною → користувачі не тиснуть.
*️⃣ Після натискання немає анімації → здається, що нічого не відбулось.
*️⃣ Форма надто довга → додати індикатор прогресу.
*️⃣ Фільтр вантажиться занадто повільно → винести частину логіки на клієнт.
*️⃣ Стартова сторінка важка → lazy-loading зображень покращить перформанс.
*️⃣ Якщо запит надсилається ще до підтвердження → користувач може випадково втратити дані.
😮💨 Баг: явно неправильна поведінка (UI ламається, дані не зберігаються, сторінка не відкривається).
😮💨 Гіпотеза: все працює, але можна зробити краще. UX — не помилка, а шанс на покращення.
*️⃣Кнопка на сайті помітна, клікабельна. Але: CTR низький. Користувачі її пропускають
*️⃣Тут немає бага. Але гіпотеза:
«Якщо змінити розмір і додати анімацію — більше людей натисне».
🔸 Google Analytics / Mixpanel / PostHog – поведінка користувачів
🔸 Chrome DevTools – перевірка логіки на фронті
🔸 Charles / Proxyman – відстеження запитів
🔸 SQL / BigQuery – аналітика поведінки
🔸 A/B-тест платформи – Optimizely, LaunchDarkly, Firebase Remote Config
✅ покращити UX
✅ виявити слабкі місця
✅ впливати на метрики
✅ зробити продукт зручнішим для людей
✏️Frontend-логи (консоль браузера, помилки у UI).
500 Internal Server Error, Timeout, NullPointerException, TypeError, 404 – усе це треба помічати.ERROR, WARN, EXCEPTION, FAILURE.😑Browser DevTools – для перегляду мережевих запитів у вебі.
☑️ Чи справді був запит і яка була відповідь?
☑️ Чи є error/exception у логах?
☑️ Чи повторюється проблема на іншому пристрої або обліковці?
☑️ Чи є залежність від дій користувача?
☑️ Чи є stacktrace, який допоможе розробнику?
Тестувальник, який вміє читати логи, завжди буде на крок попереду.
Це допомагає точніше описати баг, зрозуміти, на якому рівні виникла проблема, і навіть… зекономити час усій команді.
Наприклад, заводи Toyota використовували RCA у рамках Lean Manufacturing та Total Quality Management (TQM).
🔹 5 Whys – запитуємо “чому?” 5 разів поспіль
🔹 Fishbone Diagram – візуально розкладаємо фактори за категоріями
🔹 Pareto Analysis (80/20) – виявляємо топ-причини, що викликають більшість помилок
Падіння додатку
⬇️
--------------------------
| | | |
Код Процес Інфра Вимоги
⬇️ ⬇️ ⬇️ ⬇️
- пропущена перевірка null
- немає рев’ю-коду
- CI/CD дав збій
- нечітко описана UX-логіка
✔️Причина — неперевірене null-значення у відповіді від API. Тест-кейси цього не врахували.
☑️ Рішення:
– Додати null-check
– Розширити тестування
– Додати рев’ю перед релізами
1. Чому? — API повертає помилку
2. Чому? — не враховані спецсимволи
3. Чому? — не було валідації
4. Чому? — QA не залучили до написання вимог
5. Чому? — процес вимог не включає тестувальників
✅ Запобігання повторним дефектам
✅ Оптимізація процесів (виявляються слабкі місця)
✅ Зниження витрат (менше часу на фікси у проді)
✅ Покращення документації, вимог, тест-кейсів
✅ Загальне зростання якості продукту
✔️ Pull-to-refresh – оновлення списків свайпом вниз.
✔️ Жести свайпу – видалення, навігація, відкриття меню.
✔️ Довге натискання – виклик контекстного меню, drag-and-drop.
✔️ Нативні перемикачі, чекбокси – елементи, що відповідають платформі.
✔️ Тактильний відгук (Haptic feedback) – вібрації та системні ефекти.
✔️ Нативні анімації та переходи – плавні та оптимізовані для ОС.
❌ Платформозалежні жести – iOS: свайп від краю для навігації, Android: кнопка «Назад».
❌ Системні дії – наприклад, iOS не дозволяє змінювати жести управління (Control Center).
react-native-haptic-feedback або HapticFeedback.mediumImpact() у Flutter.❌ UI-компоненти можуть виглядати менш нативно – наприклад, прокрутка в React Native може бути менш плавною.
❌ Деякі платформозалежні функції вимагають нативних модулів – складні жести, специфічні віджети.
✔️ Базові UI-взаємодії – натискання, кнопки, прокрутка.
✔️ Довге натискання – але часто викликає дії браузера.
✔️ Деякі жести свайпу – якщо реалізовані через JavaScript.
❌ Немає справжнього pull-to-refresh – контрольований браузером.
❌ Обмежені свайпи – навігація назад/вперед контролюється браузером.
🔹 Pull-to-refresh варто тестувати тільки в нативних і кросплатформних додатках, а не в PWA.
🔹 Свайпи можуть працювати нестабільно у гібридних та веб-застосунках.
🔹 Довге натискання в PWA може викликати системні меню браузера.
🔹 Haptic feedback доступний тільки в нативних та кросплатформних застосунках.
🔹 Перемикачі, date pickers та інші UI-компоненти відрізняються залежно від типу застосунка.
👁🗨 Нативні додатки – найшвидші, але дорогі у розробці.
👁🗨 Кросплатформні рішення економлять час, але мають компроміси.
👁🗨 Гібридні застосунки та PWA – це баланс між зручністю та обмеженнями.
✔️ Високу продуктивність – напряму використовує процесор і графіку пристрою.
✔️ Доступ до всіх системних можливостей (Bluetooth, камери, датчиків, push-сповіщень тощо).
✔️ Найкращий UX, бо елементи інтерфейсу відповідають стандартам платформи.
📌 iOS – Swift, Objective-C
📌 Android – Kotlin, Java
✔️ Як працює управління пам’яттю (наприклад, iOS може "вбивати" застосунок у фоновому режимі).
✔️ Як реагують push-сповіщення у різних станах застосунку.
✔️ Чи є специфічні особливості ОС (наприклад, різні дозволи в Android 13+).
😑 React Native – написаний на JavaScript, використовує Bridge для спілкування з нативними модулями.
😑 Flutter – використовує мову Dart і має власний графічний рушій для відображення UI.
🫠 React Native викликає нативні API через JS Bridge, що трохи уповільнює виконання.
🚀 Flutter рендерить UI власними засобами, тому працює швидше, але займає більше місця.
☑️ Перевірка продуктивності (анімації можуть лагати через міст React Native).
☑️ UI може виглядати інакше на різних платформах (особливо у Flutter).
☑️ Перевіряти інтеграцію з нативними модулями (камера, геолокація, push).
✏️Основні фреймворки: Cordova, Ionic, Capacitor.
✔️Веб-контент рендериться всередині WebView.
✔️ Можливий доступ до нативних функцій через плагіни (камера, push, GPS).
✔️ Виглядає як мобільний застосунок, але працює як веб-сторінка.
☑️ Чи правильно працює WebView на різних версіях ОС.
☑️ Чи працюють нативні плагіни (GPS, push, файловий доступ).
☑️ Продуктивність і швидкість завантаження (можливі затримки при переходах між екранами).
☑️ Відмінності в UI/UX між платформами.
✔️ Не потребує встановлення, відкривається в браузері.
✔️ Підтримує push-сповіщення, офлайн-режим (через Service Workers).
✔️ Але має обмежений доступ до системних ресурсів (немає Bluetooth, обмеження на GPS).
☑️ Чи коректно працює кешування офлайн.
☑️ Як реагує застосунок на втрату мережі.
☑️ Чи є відмінності у роботі на iOS та Android (наприклад, Safari має жорсткіші обмеження).
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0Iiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNjkxMDE0NDAwfQ.V4yMjDkJwBQzjZm30sMSq2qQ2_8xX1E0Xv6PqQ5_UXU
{{❗️НЕ ПЕРЕДАВАЙТЕ КОНФІДЕНЦІЙНУ ІНФОРМАЦІЮ (паролі, токени доступу) у JWT!
Bearer означає, що будь-яка особа або система, яка має токен, може його використовувати для доступу до ресурсу.
POST /login{GET /profile{
✅️Онлайн-магазин або портал з великою аудиторією
✅️API, яке викликають інші системи
✅️Мобільний або PWA додаток з інтерактивним бекендом
✅️Великий обсяг даних (CRM, аналітика)
✅️Рекламні кампанії чи розпродажі
✔️Має GUI і CLI
✔️Працює з HTTP, WebSocket, FTP, БД, SOAP
✔️Підходить для навантажувального тестування в UI або автоматично
✅Threads (Users): скільки одночасних юзерів (напр. 100)
✅️Threads: 100
✅️Ramp-Up: 60
✅️Loop Count: 10
✅️HTTP Request: GET /api/data
✅️Constant Timer: 100 мс
✅️Assertion: Response code = 200
✅️Start: 50 Threads
✅️Add: 50 кожні 30 сек
✅️Досягти: 1000 Threads
✅️Спостерігайте: Error %, тривалість відповіді, CPU, RAM
✅️Thread Group 1: 100 Threads, Ramp-Up: 60
✅️Thread Group 2: 1000 Threads, Ramp-Up: 5, Start Delay: 120 сек
✅️Threads: 100
✅️Ramp-Up: 60
✅️Loop: Forever
✅️Scheduler: ON → Duration: 28800 сек (8 годин)
✅️Той самий сценарій з Threads: 100, 200, 400
✅️Loop Count: 10
✅️Threads: 10
✅️Ramp-Up: 10
✅️Loop Count: 100
✅️Sampler: JDBC Request або HTTP POST до API
✅️Якщо API — надсилаємо великі payload'и
✅️Якщо БД — запити типу SELECT * FROM orders WHERE date BETWEEN ...
✅️CSV Data Set Config: файл з параметрами для підстановки (напр. айдішники, дати)
✅️Assertion: перевіряємо, що відповідь не порожня / статус = 200
Він працює як проксі з логікою, часто використовуючи маршрути, плагіни або фільтри для контролю потоку даних. Це перша точка контакту клієнта з системою, яка може сильно впливати на безпеку, швидкість і стабільність.
❓ Як реалізувати єдину точку входу?
❓ Як захистити внутрішню архітектуру?
❓ Як керувати доступом, логуванням і навантаженням?
🎥 Маршрутизація — розподіл запитів на відповідні сервіси
🎥 Аутентифікація та авторизація — перевірка токенів і прав
🎥 Rate limiting — захист від DDoS і перевищення лімітів
🎥 Кешування — зменшення навантаження на бекенд
🎥 Трансформація даних — зміна формату запитів/відповідей
🎥 Логування і моніторинг — фіксація всієї активності
😑 Один запит на api.mysite.com може всередині бути розподілений між /auth, /products, /orders
😑 Gateway обмежує зовнішні інтеграції лише дозволеними методами
😑 Уся автентифікація зосереджена в одному місці
😑 Внутрішні сервіси ізольовані від зовнішнього світу
💖 Kong — open-source з розвинутим ком’юніті
💖 NGINX — легкий, швидкий, зручний для кастомізації
💖 Amazon API Gateway — хмарне рішення для AWS
💖 Spring Cloud Gateway / Zuul — частина екосистеми Java
😑 Gateway може змінювати поведінку API — це слід враховувати під час тестування
😑 Статуси 403, 429, 502 — часто приходять не від самого API, а від gateway
😑 Rate limiting варто перевіряти з кількома запитами поспіль
😑 Приклад edge-case: зламаний токен, перевищення розміру запиту, повторне надсилання
😑 У проєктах, де авторизація “на gateway”, логіка токенів і ролей тестується саме тут
💢 Одна точка відмови — якщо gateway падає, недоступні всі сервіси.
💢 Помилки в налаштуваннях — можуть заблокувати легальні запити або відкрити доступ тим, кому не слід.
💢 Мішень для атак — gateway першим приймає запити ззовні, тому часто стає ціллю.
💢 Вразливість через застаріле ПЗ — без оновлень можуть з’явитися діри в безпеці.
💢 Відсутність резерву — без запасного плану збій gateway = збій системи.
request flow через Gateway та як правильно перевіряти rate limiting.*️⃣Якщо змінити колір кнопки «Купити», CTR зросте.
*️⃣Якщо додати індикатор прогресу в анкеті, більше користувачів її завершать.
*️⃣Якщо замінити модальне вікно на інлайн-повідомлення, конверсія не впаде.
😑Тестувальник помічає: форма реєстрації довга, і часто користувачі не доходять до останнього кроку.
😑Чи коректно працюють варіанти А і B?
😑Чи зібрані події для аналітики?
😑Чи все видно в DevTools / Network / аналітичних подіях?
*️⃣Кнопка «Підтвердити» виглядає неактивною → користувачі не тиснуть.
*️⃣ Після натискання немає анімації → здається, що нічого не відбулось.
*️⃣ Форма надто довга → додати індикатор прогресу.
*️⃣ Фільтр вантажиться занадто повільно → винести частину логіки на клієнт.
*️⃣ Стартова сторінка важка → lazy-loading зображень покращить перформанс.
*️⃣ Якщо запит надсилається ще до підтвердження → користувач може випадково втратити дані.
😮💨 Баг: явно неправильна поведінка (UI ламається, дані не зберігаються, сторінка не відкривається).
😮💨 Гіпотеза: все працює, але можна зробити краще. UX — не помилка, а шанс на покращення.
*️⃣Кнопка на сайті помітна, клікабельна. Але: CTR низький. Користувачі її пропускають
*️⃣Тут немає бага. Але гіпотеза:
«Якщо змінити розмір і додати анімацію — більше людей натисне».
🔸 Google Analytics / Mixpanel / PostHog – поведінка користувачів
🔸 Chrome DevTools – перевірка логіки на фронті
🔸 Charles / Proxyman – відстеження запитів
🔸 SQL / BigQuery – аналітика поведінки
🔸 A/B-тест платформи – Optimizely, LaunchDarkly, Firebase Remote Config
✅ покращити UX
✅ виявити слабкі місця
✅ впливати на метрики
✅ зробити продукт зручнішим для людей
Щоб працювати з різними середовищами (dev/stage/prod), варто використовувати власні базові URL, токени, параметри у вигляді змінних.
{{base_url}}/users замість повної адреси вручну.Postman підтримує JavaScript для автоматизації: можна обчислити токен, згенерувати дату, виконати перевірку.
pm.test("Status code is 200", function () {Запити можна об’єднувати у колекції — за функціональністю або мікросервісом.
Допомагає запускати всі запити з колекції по черзі, з різними наборами даних (CSV/JSON).
Забезпечують запуск запитів за розкладом — щогодини, щодня. Дають змогу виявити збої API після релізу.
Дозволяють симулювати відповіді API, навіть якщо бекенд ще не реалізований.
Відповіді можуть відображатися у вигляді таблиць, графіків — за допомогою шаблонів (HTML + Handlebars).
Інтеграція з CI/CD: запуск тестів через Newman у пайплайнах.
Перевірки статус-кодів, значень у полях, структури JSON тощо.
pm.response.to.have.jsonBody('user.id');😑 Як працюють типи авторизації (Bearer, Basic Auth, API Key)
😑 Як писати умовні конструкції у тестах (if-else на різні відповіді)
😑 Як використовувати глобальні, локальні та середовищні змінні
😑 Як зберігати динамічні значення між запитами (pm.environment.set)
😑 Як організовувати колекції для зручного користування і командної роботи
HTTP-запит (наприклад, GET/products) на домен, пов’язаний з gateway (наприклад, api.mysite.com).HTTPS) розшифровується (термінується) на стороні gateway або load balancer, і далі в системі йде як звичайний HTTP.client_id. Якщо щось не так — повертається 401 або 403.429 Too Many Requests./products перетворити на /api/v1/items) і передати далі в мікросервіс.Якщо CORS налаштовано неправильно, frontend не отримає відповідь навіть при правильному запиті.
😑 Надішли більше запитів, ніж дозволено (наприклад, 11 при ліміті 10/хв)
😑 Перевір 429 статус та повідомлення
😑 Зачекай хвилину — чи обнуляється ліміт?
😑 Різні ролі — різні обмеження?
GET /products запитів протягом хвилини😑 Без токена, з битим або простроченим токеном
😑 401 чи 403 — чи відповідає статус очікуванню?
😑 Перевір дозволи для кожної ролі
GET /orders без токена — очікуємо 401/admin — очікуємо 403/reports, але не до /users😑 Валідні та невалідні URl
😑 Заборонені шляхи для звичайного користувача
GET /api/v1/products → має потрапити до відповідного сервісуGET /api/v1/nonexistent → 404 Not Found/admin/settings → 403😑 Чи зберігається Authorization при редиректах
😑 Чи правильні CORS-заголовки для фронтенду
app.example.com має правильні CORS-заголовкиevil.com → перевірити, що CORS блокує😑 Великі тіла запитів
😑 Довгі URI
😑 Повторний запит з тим самим токеном
POST із тілом 1 МБ JSON → чи обробляється без помилки?GET-запит з 250 символами в URI — чи не обрізається?POST /checkout з однаковим токеном — чи не створює дубль?😑 Виявити нестійкість у коді
😑 Перевірити обробку помилок (error handling)
😑 Запобігти крашам і втраті даних
😑 Підвищити довіру до продукту: баги часто ховаються саме в edge-case’ах
🔸 Ввести в поле “Телефон” — текст: abcdef
🔸 Вставити у форму emoji або спецсимволи
🔸 Натиснути “Зберегти”, не заповнивши обов’язкові поля
🔸 Ввести занадто довгий текст (500+ символів у полі “Ім’я”)
🔸 Відправити запит без токена авторизації
🔸 Передати userId: null або email: "123"
🔸 Викликати PUT замість POST
403 / 401 / 422 — чи правильно реагує бекенд?🔸 Вимкнути інтернет і натиснути “Оновити”
🔸 Повернути екран під час завантаження
🔸 Кілька разів швидко натиснути на кнопку
🔸 Надати доступ до камери, а потім заборонити
✔️ Подумати: що піде не так?
✔️ Визначити точку входу (UI/API/дія користувача)
✔️ Ввести дані або умову, яка порушує норму
✔️ Передбачити очікувану негативну реакцію
✔️ Перевірити, чи не зламалась система
🔹 Повідомлення про помилки мають бути чіткі й зрозумілі
🔹 Логувати результати — негативне тестування допомагає писати хороші тест-кейси
🔹 Враховувати edge-case’и: null, пусті поля, нестандартні мови, неочікувані типи даних
🔹 Не обмежуватись UI — тестувати також API, базу, мережу
