Що таке Volume Testing? Навчайтеся на прикладах
Томас Гамільтон
⚡ Розумний підсумок
Об'ємне тестування піддає застосунок роботі з дуже великою кількістю даних, щоб побачити, як поводяться сховище, запити та час відгуку зі зростанням бази даних. Його також називають тестуванням перевантаження, і воно масштабує дані, а не кількість користувачів.
Що таке Volume Testing?
Тестування обсягу це тип тестування програмного забезпечення, де програмне забезпечення піддається величезному об’єму даних. Його також називають випробування повені. Об’ємне тестування виконується для аналізу продуктивності системи шляхом збільшення обсягу даних у базі даних.
За допомогою тестування обсягу можна вивчити вплив на час відгуку та поведінку системи під час роботи з великим обсягом даних.
Наприклад, сервіс потокової передачі музики може бути протестований з каталогом із 50 мільйонів tracks та таблицю історії прослуховування, що містить мільярди рядків, щоб побачити, чи пошукові запити та рекомендації все ще повертаються в прийнятний час.
Зверніть увагу на відмінність: об'ємне тестування збільшує обсяг даних система виконується. Збільшення кількість одночасних користувачів це навантажувальне тестування, яке є іншим тестом з іншою метою.
Переваги об’ємного тестування
- Раннє виявлення проблем з потужностями дозволяє уникнути значно вищих витрат на їх вирішення у виробництві
- Це допомагає швидше запустити плани масштабованості
- Раннє виявлення вузьких місць
- Це гарантує, що ваша система тепер здатна використовуватися в реальних умовах
Навіщо проводити об'ємне тестування?
Метою виконання об’ємного тестування є
- Перевірка продуктивності системи при збільшенні обсягів даних у базі даних
- Визначте проблеми, які ймовірно виникнуть, коли набір даних стане великим
- Визначити точку, в якій стабільність системи погіршується
- Volume Testing допоможе визначити ємність системи або програми – нормальний і великий обсяг
Як проводити об'ємне тестування
Під час об’ємного тестування потрібно перевірити наступні речі
- Перевірте, чи немає втрати даних
- Перевірте час реакції системи
- Перевірте, чи правильно зберігаються дані
- Перевірте, чи дані перезаписані без сповіщення
- Перевірте, чи дійсно з’являються попередження та повідомлення про помилки, коли досягнуто ліміту гучності
- Перевірте, чи великий обсяг даних впливає на швидкість обробки
- Переконайтеся, що система має пам'ять і ресурси сховища, необхідні для тому
- Переконайтеся, що об'ємний тест охоплює всю систему, а не окремий компонент
- Чи існує ризик, якщо обсяг даних перевищує вказаний
- Встановіть, чи існує гарантія того, що обсяг даних не перевищить заданий максимум
Найкращі практики для тестування великих обсягів
Кілька наведених нижче практик є спільними з навантажувальним тестуванням, оскільки вони зазвичай виконуються в одному середовищі. Специфічні для обсягу методи стосуються самого набору даних:
- Зупиніть усі сервери та перевірте всі журнали
- Перед навантажувальним тестом вручну виконайте сценарій програми
- Щоб отримати найбільш корисні результати, змініть кількість користувачів
- Щоб подолати ліцензійні обмеження, збалансуйте час на обдумування
- Будьте обережні з новою конструкцією
- Проаналізуйте варіант використання для покращення після того, як буде встановлено базовий рівень
- Повторення певних частин об’ємного тестування стає неминучим, якщо є вузьке місце продуктивності
Об'ємне тестування проти навантажувального тестування
| Тестування обсягу | Тестування навантаження |
|---|---|
|
|
|
|
Проблеми в об'ємному тестуванні
- Важко створити фрагментацію пам'яті
- Динамічна генерація ключів
- Реляційний Integrity згенерованих даних
Як цей тест порівнюється з іншими тестами продуктивності
Тестування продуктивності – це сімейство тестів, які відрізняються формою прикладеного навантаження, тому їх так легко сплутати.
| Тип тесту | Що збільшено | Питання, на яке воно відповідає |
|---|---|---|
| Тестування навантаженням | Одночасні користувачі, до очікуваного піку | Чи досягає він цільових показників за нормальних пікових умов? |
| Об'ємне тестування | Дані, що зберігаються в базі даних | Чи справляється воно зі зростанням набору даних? |
| Стресові випробування | Навантаження понад допустиму вантажопідйомність, до відмови | Де воно ламається і як? |
| Спайкове тестування | Завантаження, миттєво та надзвичайно | Чи виживає воно та оговтується від шоку? |
| Випробування на витривалість | Тривалість, при нормальному навантаженні | Чи знижується продуктивність з часом? |
| Випробування замочуванням | Тривалість, ресурси для перегляду | Чи є витоки пам'яті або дескрипторів? |
| Тестування стабільності | Різні умови | Чи залишається він надійним, коли умови змінюються? |
Найважливіша тут відмінність: Об'ємне тестування масштабує дані, навантажувальне тестування масштабує користувачів. Звіт, який виконується за дві секунди для десяти тисяч рядків і за дві хвилини для десяти мільйонів рядків, має проблему з обсягом, а не з навантаженням, і жодна додаткова потужність сервера її не вирішить.
Як генерувати тестові дані для об'ємного тестування
У розділі про проблеми зазначається, що отримання реалістичних даних є складною частиною об'ємного тестування. На практиці використовуються чотири підходи, і кожен з них передбачає певний компроміс.
| Підхід | реалізм | Основний недолік |
|---|---|---|
| Копія виробничих даних | Найвищий | Розкриття конфіденційності та відповідності вимогам |
| Замаскована виробнича копія | Високий | Маскування може порушити цілісність посилань |
| Синтетична генерація | Medium | Розподіл може не відповідати дійсності |
| Відтворений виробничий трафік | Високий | Потрібна інфраструктура захоплення |
Яким би шляхом ви не обрали, мають бути виконані три властивості, інакше тест не виміряє нічого корисного.
- Референційна цілісність. Кожен зовнішній ключ має бути розв'язаний. Мільйон рядків-сиріт активує механізм сховища, але ніколи не перевіряє шляхи об'єднання, які фактично використовує програма.
- Реалістична кардинальність. Якщо виробнича таблиця містить десять мільйонів рядків для двохсот клієнтів, генерація десяти мільйонів рядків для десяти мільйонів клієнтів створює зовсім інші плани запитів.
- Реалістичний розподіл. Реальні дані спотворені. Рівномірно випадкові дані приховують гарячі розділи та конфлікти індексів, які спричиняють інциденти у виробництві.
Практичне застереження щодо конфіденційності. Копіювання виробничих даних у тестове середовище є найпоширенішою причиною витоку даних під час тестування. Маскуйте особисті поля до того, як копія вийде з виробничого середовища, а не після цього.
