Навантажувальне тестування Web-систем. Завершуємо підготовку

У статті та статті описані моменти, на які варто звертати увагу при підготовці до виконання тесту з високим навантаженням на Web-систему з Web-інтерфейсом.

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

Розбивати тестовий сценарій

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

Візьмемо якийсь особистий кабінет банківського сектора. Ми перевіряємо як працює особистий кабінет при навантажувальному тестуванні. У нас є певні кроки:

1. Відкрити головну сторінку.
2. Перейти на сторінку особистого кабінету.
3. Увійти в систему.
4. Перевірити стан своїх рахунків.
5. Оплатити будь-яку послугу.
6. Виконати переклад на якусь карту.
7. Виконати вихід з системи.

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

Примірний склад тестів з 7 різних наборів.

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

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

При розробці автоматизованих функціонального тестування прийнято розбивати один великий набір кроків на більш дрібні функції. Такий же принцип застосовний і в навантажувальному тестуванні.

Використання різних наборів в одному тесті

Чим більше тестована система, тим більше можливих варіантів використання її може бути. У попередньому розділі ми розглянули як можемо розбити одну велику послідовність на кілька наборів і використовувати їх у різних тестах. Але що робити коли ми запускаємо тест на кілька 1 000 користувачів.

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

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

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

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

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

Використовувати різні значення швидкості обміну даними для запусканих наборів

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

Пропоную розглянути ситуацію, коли сервер підтримує тільки 10 одночасних з'єднань. З ним одночасно працюватимуть 20 користувачів. Ми знаємо, що коли той чи інший користувач закінчив працювати, то він звільняє з'єднання і наступний може активно починати його використовувати. Якщо для частини користувачів ми обмежимо швидкість обміну даними, то у нас збільшиться і час отримання даних. Через це у нас збільшується загальний час роботи всього сценарію.

Якщо у нас досить багато таких «повільних» користувачів, то ми заповнимо весь канал сервера, а значить нові, які будуть намагатися до нього підключиться, отримають відмову після закінчення часу очікування підключення. Іншими словами з 20 користувачів кілька можуть і зовсім завершиться з помилками.

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

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

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

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

Ув'язнення

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

Деталізація дозволяє нам скласти велику кількість тестів з різним набором. Що наближає наші тести до реальних навантажень, які будуть проводитися на Web-системі.

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

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

Вдалих вам тестів і хороших результатів.