Меню

Підручник з об’ємного тестування: Приклади та інструменти об’ємного тестування

  • Головна
  • Інший
  • Підручник з об’ємного тестування: Приклади та інструменти об’ємного тестування

volume testing tutorial

Спробуйте Наш Інструмент Для Усунення Проблем

Огляд об'ємного тестування:

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

Усі ми повинні знати про функціональне та нефункціональне тестування, але чи пам’ятаєте ви про те, що нефункціональне тестування так само важливо, як і функціональне тестування? Часом у короткочасних випусках ми, як правило, ігноруємо це нефункціональне тестування, чого в ідеалі ми не повинні робити.

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

Об

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

Що ви дізнаєтесь:

Що таке об'ємне тестування?

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

База даних розтягується до порогової точки, додаючи до неї велику кількість даних, а потім система перевіряється на відповідь.

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

Коли це тестування є обов’язковим?

В ідеалі кожне програмне забезпечення або додаток слід перевіряти на обсяг даних, але в деяких випадках, коли дані не будуть важкими, ми, як правило, уникаємо цього тестування. Але в деяких випадках, коли дані обробляються в МБ або ГБ щодня, тоді, безумовно, слід проводити об'ємне тестування.

Нижче наведено кілька прикладів з мого власного 8-річного досвіду, які пояснюють частину «коли»:

Приклад 1:

Одним із моїх починань була велика система, яка включала як веб-програму, так і мобільну програму. Але сама веб-програма мала 3 модулі, якими обробляли 3 різні команди.

Часом навіть у нас база даних ставала повільною, коли ми всі разом додавали дані для тестування. Це дратувало, і раніше робота ускладнювалась через величезний обсяг даних і для полегшення роботи, нам доводилося досить часто очищати БД.

Дані, якими обробляла система «в реальному часі», складали близько ГБ, отже, у порівнянні з мобільним додатком веб-додаток дуже часто тестували на обсяг даних. Команди контролю якості веб-додатків мали власні сценарії автоматизації, які запускалися вночі та проводили це тестування.

Приклад 2:

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

Таким чином, об'ємне тестування проводилося регулярно, а ефективність БД відстежувалась щохвилини щодо будь-яких проблем.

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

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

До його обмежень та викликів можна віднести:

  • Важко створити точну фрагментацію пам'яті.
  • Динамічне створення ключів складно.
  • Створення ідеального реального середовища, тобто репліки реального сервера, може бути складним.
  • Засоби автоматизації, мережа тощо також впливають на результати тестування.

Тепер ми зрозуміли коли нам потрібно провести такий тип тестування. Давайте також зрозуміємо 'Чому' ми повинні проводити це тестування, як у, меті або меті проведення цього тестування.

Чому я повинен прагнути до об'ємного тестування?

Підключені дані

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

Нижче наведено кілька можливих причин проведення цього тестування:

  • Найголовнішою потребою є аналіз продуктивності вашої системи на основі збільшення даних. Створення величезного обсягу даних допоможе вам зрозуміти продуктивність вашої системи з точки зору часу відгуку, втрати даних тощо.
  • Визначте проблеми, які виникатимуть із величезними даними та граничною точкою.
  • За межами стійкої або порогової точки поведінка системи, тобто якщо аварійне завершення роботи БД стає неактивним або закінчується час очікування.
  • Впровадження рішень для перевантаження БД і навіть їх перевірка.
  • Виявлення крайньої точки вашої БД (яку неможливо виправити), після якої система вийде з ладу, і, отже, потрібно вжити заходів обережності.
  • У разі наявності декількох серверів БД, з’ясування проблем зі зв’язком БД, тобто найбільш схильних до їх виходу з ладу тощо.

Тепер ми знаємо важливість та причину проведення цього тестування.

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

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

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

Який мій контрольний список для цього тестування?

CheckList

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

Моменти, які слід пам’ятати:

  • Тримайте розробників у курсі вашого плану тестування, оскільки вони знають багато про систему і можуть надати вам дані та навіть вузькі місця.
  • Перш ніж розробити стратегію тестування, добре зрозумійте фізичний аспект, як у конфігураціях сервера, оперативної пам’яті, процесорі тощо.
  • Розумійте складність БД, процедури, сценарії БД тощо, наскільки це можливо, щоб Ви могли окреслити складність Вашої системи в цілому.
  • Підготуйте інформатику, тобто графіки, таблицю даних тощо, якщо це можливо для нормального обсягу даних та наскільки добре працює система, це допоможе вам переконатися, що перед тим, як напружувати БД, продуктивність відповідає нормальному завантаженню даних. Це також допоможе вам переконатись, перш ніж переходити до наголошуючої частини, що немає проблем, які потребують виправлення для вашого тесту обсягу.

Нижче наведено кілька прикладів, які ви можете додати або використовувати у своєму контрольному списку:

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

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

Об'ємне тестування проти тестування навантаження

Нижче наведено деякі основні відмінності між тестуванням обсягу та навантаження:


S.No		Об'ємне тестуванняТестування навантаження
одинТестування обсягу проводиться для перевірки продуктивності бази даних щодо великого обсягу даних у БД.Тестування навантаження проводиться шляхом зміни завантажень користувача для ресурсів та перевірки продуктивності ресурсів.
дваОсновне завдання цього тестування - «дані».Основне завдання цього тестування - «користувачі».
3База даних підкреслено максимально допустимою.Сервер напружений до максимального обмеження.
4Простим прикладом може бути створення файлу великого розміру.Простим прикладом може бути створення великої кількості файлів.

Як провести це тестування?

Тестування бази даних

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

Перед початком виконання тестового випадку переконайтесь, що:

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

Давайте розглянемо кілька зразків тестових кейсів, які ви можете використовувати у виконанні:

Перевірте це для всіх вибраних обсягів даних для тестування:

  1. Переконайтеся, що додавання даних можна виконати успішно і чи відображається це в додатку чи на веб-сайті.
  2. Перевірте, чи можна видалити дані успішно, і чи відображаються вони в додатку чи на веб-сайті.
  3. Перевірте, чи можна успішно оновити дані та чи відображаються вони в додатку чи на веб-сайті.
  4. Переконайтеся, що не відбувається втрати даних, і вся інформація відображається належним чином у додатку чи на веб-сайті.
  5. Переконайтеся, що в програмі чи веб-сторінках не минув тайм-аут через великий обсяг даних.
  6. Переконайтеся, що помилки збою не відображаються через великий обсяг даних.
  7. Переконайтеся, що дані не перезаписані, і відображаються належні попередження.
  8. Переконайтеся, що інші модулі вашого веб-сайту чи програми не аварійно завершують роботу або не вичерпують час із великим обсягом даних.
  9. Переконайтеся, що час відгуку БД знаходиться в межах допустимого діапазону.

Інструменти тестування гучності

Засоби автоматизації

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

Ми можемо запланувати тести на ранок, і результати будуть готові.

Нижче наведено перелік декількох інструментів тестування з відкритим кодом:

# 1) DbFit:

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

DbFit фреймворк тестування написаний поверх Fitness, тести пишуться за допомогою таблиць і можуть виконуватися за допомогою будь-якого інструменту Java IDE або CI.

# 2) HammerDb:

HammerDb це також інструмент з відкритим кодом, який може бути автоматизованим, багатопотоковим і навіть дозволяє виконувати сценарії під час виконання. Він може працювати з SQL, Oracle, MYSQL тощо.

# 3) JdbcSlim:

JdbcSlim команди можуть бути легко інтегровані в Slim Fitness, і він підтримує всі бази даних, які мають драйвер JDBC. Основна увага приділяється збереженню конфігурації, даних тестування та запитів SQL окремо.

# 4) NoSQLMap:

Це - це інструмент Python з відкритим кодом, який призначений для автоматичного введення атак та порушення конфігурацій БД для аналізу загрози. Це працює лише для MongoDB.

# 5) Ruby-PLSQL-специфікація:

PLSQL можна протестувати за допомогою Ruby, оскільки Oracle доступний як інструмент з відкритим кодом. Це в основному використовує дві бібліотеки: Ruby-PLSQL та Rspec.

Висновок

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

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

який найкращий завантажувач музики для ПК - -

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

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

Рекомендована література

^