Демонстраційна база швидко відкривається, презентація переконлива, а справжня перевірка починається перед відправленням машин: склад проводить документи, інтеграція надсилає замовлення, керівник запускає звіт. Для корпоративної інформаційної системи K2 ERP навантажувальне тестування має відповісти на конкретне питання — чи зможе команда виконати критичні операції в такий момент.
Перетворіть обсяги на сценарій зміни
Місячна кількість рухів, денний потік рядків і кількість одночасних користувачів описують різні вимоги. У матеріалі K2 про навантажувальне тестування згадані 100 мільйонів рухів на місяць, 100 тисяч рядків на день та тисячі користувачів як запити під час обговорення майбутніх впроваджень. Ці числа не є опублікованим результатом готового еталонного випробування.
Підготуйте профіль підприємства: пікові п’ятнадцять хвилин, типовий і найбільший документ, популярні товари, кількість складів, частоту імпорту й час запуску звітів. Рівномірний потік на тесті може приховати чергу, яка виникне перед останньою машиною. Середня температура сервера іноді заспокоює лише того, хто вже пішов додому.
Генератор готує дані для перевірки
Генератор K2 ERP створює довідники номенклатури, контрагентів, місць розташування й контейнерів. У показаній версії документи генеруються для WMS: можна обрати продажі, закупівлі та складські операції й увімкнути проведення.
У відео записано 630 документів за 80 секунд. Це час підготовки даних у конкретному демонстраційному запуску. Він не визначає швидкість роботи тисяч людей у браузері. Так само паралельні процеси генерації, описані для масштабних тестів, не тотожні одночасним інтерактивним користувачам.
Вимірюйте досвід користувача й причину затримки
Час серверної відповіді та момент появи готового результату в браузері варто вимірювати окремо. Велика таблиця може довго відображатися навіть після завершення запиту. На сервері затримку можуть створювати очікування з’єднання, блокування, читання диска або запис журналу транзакцій.
Замість одного середнього значення погодьте розподіл часу відповіді, зокрема p95, кількість успішно завершених операцій, помилки й довжину черги. Якщо p95 дорівнює двом секундам, приблизно 95% виміряних операцій завершилися не довше ніж за дві секунди. Це приклад читання метрики; прийнятну межу визначають окремо для вашого процесу.
Перевірте пік, тривалу роботу та повтори
Почніть з окремої операції, потім поєднайте приймання, відвантаження, імпорт і звітність. Додайте раптовий пік і тривалу роботу, щоб побачити накопичення черг та вплив фонового обслуговування бази. Дані повинні мати реалістичну нерівномірність: кілька популярних товарів здатні створити інші конфлікти, ніж рівномірно розподілений каталог.
Окремий критерій — коректність після тайм-ауту та повторного запиту. Чи не з’явилося подвійне відвантаження? Чи відповідає залишок документам? Чи відновилася звичайна швидкість після піку? Швидко отримана неправильна цифра навряд чи стане перемогою бухгалтерії.
У PostgreSQL аналізують плани запитів, очікування та стан обслуговування даних. Оптимізацію перевіряють на тому самому сценарії: додатковий індекс може прискорити читання й водночас збільшити роботу під час запису. Вибір змін має спиратися на вимірювання конкретної бази.
Погодьте протокол приймання до запуску
Протокол має містити версію системи, конфігурацію середовища, обсяг і структуру даних, сценарії, темп надходження запитів, тривалість, критерії швидкодії й звіряння обліку. Збережіть результати та повторіть зіставний тест після змін. Так можна пояснити, що саме дало ефект, і прийняти рішення про робочу конфігурацію.
Для підготовки сценаріїв корисні перевірки звітів і первинних документів K2 ERP. Принесіть на обговорення кількість документів за зміну, пікові операції й допустимий час очікування. Саме ці дані перетворюють загальне «нам потрібна швидка ERP» на перевірювану вимогу.
Почніть із безкоштовної хмари K2 ERP. Для обговорення свого процесу напишіть у WhatsApp +380679016322. Підготуйте приклади без конфіденційних даних і перелік результатів, які хочете перевірити.
