Складності навантажувального тестування – інтерв'ю з Володимиром Ситніковим (Netcracker) і Андрієм Дмитрієвим



Напередодні конференції Heisenbug ми поговорили про тонкощі навантажувального тестування з Володимиром vladimirsitnikov Ситніковим (вже 10 років працює над продуктивністю і масштабованість Netсracker OSS — ПЗ, яке використовується операторами зв'язку для автоматизації процесів управління мережею і мережевим обладнанням, захоплюється питаннями продуктивності Java і Oracle Database) і Андрієм real_ales Дмитрієвим (java-програміст, розробляв JDK в компанії Sun і Oracle, керував командою розробки під Android в QuickOffice. У компанії Netcracker створював і потім керував підрозділом, який займається навантажувальних тестуванням OSS-платформи Java, OracleDB, JMeter, etc.)).

JUG.ru: Розкажіть, будь ласка, про свою роботу і тієї ролі, яку відіграє в ній навантажувальне тестування.

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

Netcracker — запроваджена у багатьох телеком-операторів платформа, майже на 100% написана на Java. Створена вона давно і працює з величезною кількістю сторонніх заліза і софта. Тому є можливість експериментувати з абсолютно різними кейсами — продуктивністю мережі, фронтэндом, SQL-запитами тощо. Тобто у нас не просто є один кейс, який ми все вирішуємо. Кейси весь час нові, тому цікаві.

Моїм завданням був пошук проблем у рішеннях Netcracker. При виявленні проблеми я проводив поверхневий аналіз, постачав її додатковими деталями, знімав необхідні метрики (робив дампи) і, умовно кажучи, передавав завдання перформанс-інженер.

Володимир Ситников: Я — перформанс-архітектор. Моє завдання — аналіз результатів вимірів, а також вироблення рекомендацій, які заміри краще провести, щоб побачити проблеми того чи іншого класу. Для вирішення проблем зазвичай треба не тільки провести ці виміри, але і зрозуміти результати. Тому я з дня у день займаюся тим, що дивлюся на хмару цифр і намагаюся витягнути з нього якусь корисну інформацію.

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

JUG.ru: З якихось питань, на ваш погляд, має починатися навантажувальне тестування? Можна виділити кілька найважливіших?

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

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

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

Ніколи не буває так, що ми зібрали всі дані і наступні 3 місяці тестували без будь-яких відхилень від розробленого на старті плану. Завжди вносяться якісь коментарі.

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

Складності тестування enterprise-додатків
JUG.ru: Підводні камені при тестуванні enterprise-додатків — назвіть, будь ласка, пару найбільш очевидних.

Андрій: Це не підводні камені, це ціле мінне поле.

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

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

Замовник вирішив, що все це — один кейс, а за фактом користувач запускає ці кейси по-різному (тобто кейси потрапляють в різну статистику). Виходить, замовник може вважати, що кейс виповнюється 100 тис. разів, а за фактом користувачі створюють його 200 тис. разів.

Другий момент: дуже часто ми стикаємося з відсутністю всіх необхідних прав для тестування на обладнанні замовника. І тут починається… Нам потрібно поставити фреймворк для тестування, для цього потрібно отримати 100500 погоджень, потім потрібно отримати доступ до бази даних і т. п. і т. д. Без необхідних прав доводиться вивертатися.

Наприклад, ми пішли до замовника і провели навантажувальний тест, який використовував 500 тис. деяких юнітів з бази даних. В рамках тесту ми підключилися прямо до бази даних замовника, і включили юнітам прапорець, що вони використані. Припустимо, всього в базі 600 тис., а 500 тис. ми вже «спалили». І нам доводиться вигадувати спосіб, як 500 тис. цих об'єктів повернути в початковий стан. Якщо ми про це не подумаємо заздалегідь, то у нас буде лише один шанс провести це навантажувальне тестування.

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

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

JUG.ru: Які дії необхідно виконати ще до початку навантажувального тестування?

Андрій: Зовсім проста відповідь — це функціональні тести.

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

Замість приклад: якийсь час назад ми відкочували базу даних Oracle до певного чекпоінти. Ми проводили тест, знімали характеристики і повертали БД в початковий стан за допомогою rollback-а. Ну і в якийсь момент ми забули виконати останній крок. Коли ми потім запустили тести, вони почали валитися. І докопатися до справжньої причини було дуже важко, тому що інформація, що ми не відкотилися, дуже важко відстежується.

JUG.ru: Наскільки детальну інформацію про програму необхідно мати перед тим, як планувати тестування?

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

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

Є такий приклад. Уявіть собі, що замовник каже: «У нас буде 3 тис. кейсів, але найпопулярніші з них — 10 — 20». Ми починаємо їх тестувати: пишемо тести, щоб ці кейси генерувалися 100 — 200 тис. разів за добу. Після запуску тесту виявляється, що ці топові кейси велике навантаження не викликають: ми бачимо, що CPU на нулі, жорсткий диск майже не завантажений. А потім з'ясовується, що серед цих 3 тис. кейсів насправді є сценарії, які викликаються всього 300 разів за добу (і ми їх, звичайно ж, проігнорували), але це які-небудь важкі пошуки, які можуть генерувати левову частку навантаження, наприклад, на жорсткий диск.

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

Володимир: Андрій торкнувся дуже цікавих підводних граблів — як правильно оцінити складність операції. Повинна бути якась експертиза (чуття розробника або аналітика), яка буде підказувати, де потенційно проблемні сценарії, а де — ні.

Можна максимально деталізувати інформацію про проект, але ніхто з цим не стане працювати. У навантажувального тестування, принаймні в enterprise-додатках, є обмеження, тому треба якимось чином виділити найбільш важливі деталі для тестування. Як це ми можемо робити? Ми можемо або слідувати тому, що говорить замовник («дуже важливо, щоб ця кнопка у нас натискалася за 2 десятих секунди, тому що її буде натискати віце-президент на демці»), або слідувати якомусь чуттю розробника або аналітика, яка повинна підказувати, що така-то функціональність важко реалізується, тому її необхідно краще протестувати.

Відповідно, в реальних проектах ми стикаємося не тільки з цифрами щодо кейсів, але з якимись експертними оцінками по складності цих кейсів.

JUG.ru: Яку роль «глюки обладнання» грають у навантажувальному тестуванні?

Володимир: На мій погляд, ситуації, коли обладнання не працює так, як від нього очікувалося, у нас бувають досить рідко. Можна багато говорити про те, що пам'ять і жорсткі диски періодично ламаються, але у нас це трапляється нечасто. І, як правило, якщо у сервера ламається жорсткий диск, ми втрачаємо стенд і, відповідно, час на відновлення або побудова сервера з нуля.

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

Однак набагато частіше трапляється, що ми стикаємося не з поломками, а з обмеженнями обладнання — з тим, що залізниця не справляється з навантаженням. Мені здається, боротися з цим можна, використовуючи два основних підходи. Перший — розподіл навантаження на жорсткий диск за часом (наприклад, ми не вдень виконуємо якусь операцію, а перекладаємо її в нічний режим, коли користувач нічого не робить з системою). Другий — тупий оптимізація запитів.

JUG.ru: Який «перезаклад» за обсягами даних, з вашого досвіду, необхідно закладати при навантажувальному тестуванні?

Андрій: Зазвичай ми закладаємо 120-150% від базового навантаження. Але якщо ми очікуємо, що якісь компоненти слабкі, тобто не готові до такого роду навантажень, або якщо у нас є підстави вважати, що оцінки замовника брешуть, можемо підвищувати «перезаклад».

І ще ми іноді перевіряємо на 400%. Зазвичай ми не робимо тестування всієї системи на 400%. Ми виділяємо і тестуємо компоненти, щоб перевірити, наскільки стабільно вони працюють. Набагато простіше потюнить (потестувати, а потім потюнить) один маленький компонент, якщо ми вважаємо, що він буде потенційно слабкою ланкою.

JUG.ru: Часто такий перезаклад по навантаженню рятує?

Володимир: Часто чи ні — складно виміряти. Чи Часто вам потрібен запасний парашут?

Але я скажу по-іншому. Часто буває, що у «бойовий» системі відбувається якась нештатна ситуація, наприклад, одна з компонент зависла, в ній застрягли дані. Потім її розблокувало, всі ці дані полізли далі. В ідеальному світі, звичайно, скрізь є обмежувачі, але в реальності трапляється, що таке залипання запросто призводить до шквалу яких-небудь повідомлень — підвищеному навантаженні на всі інші частини нашого стека. Ми звичайно можемо сказати, що таке не підтримуємо, тому система і впала. Але виглядає це не дуже професійно. Буде краще, якщо система буде хоч якось відпрацьовувати або, принаймні, не йти в несознанку.

Вибираючи між швидкістю і якістю
JUG.ru: Більш якісне тестування вимагає більшого часу, але час зазвичай обмежена. Як правильно знайти баланс швидкості і якості? Як підвищити швидкість тестування?

Володимир: Тестувати треба «звідси і до обіду».
З приводу підвищення швидкості тестування. На мій погляд, є досить просту відповідь: треба розбивати складну систему на шматочки і тестувати спочатку все по компонентам. Це дає прискорення. Коли є якась система, у нас є багато сценаріїв, але вони ніколи не підходять до тестування в один момент. Як правило, ми отримуємо шматочки, тому спочатку тестуємо ці шматочки незалежно, потім, коли всі більш або менш откатано, будуємо тести, які втягують в себе одночасно багато компонент.

Андрій: У продовження розмови про компонентах…
Є таке поняття, як заглушки сторонніх систем — стаби. Коли ми тестуємо рішення поза оточення замовника, у нас немає реального заліза і реальних сервісів, які видають телефонні номери, імена, IMEI і т. п. Все це ми синтетично емуляціях з допомогою «заглушок», які називаємо або емуляторами, або стабами. Зазвичай ми починаємо тестування з цих стаб. Стаби — адже це теж частина проекту, вони теж повинні витримувати певне навантаження. Нехай вони відповідають односкладово, але вони теж пишуться з використанням нашого внутрішнього фреймворка. І у цього фреймворку теж можуть бути якісь перформанс-проблеми. Тому ми починаємо тестування з стабів, навантажуючи їх у 40-50 разів більше, ніж вони будуть завантажені на тестах. Потім нам це допомагає не перейматися цим питанням на end-to-end тестах.

JUG.ru: чи Існують типові проблеми аналізу отриманих результатів (грубо кажучи, неправильно подивилися в «хороші» дані)?

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

Андрій: Напевно, я погоджуся з Володею. Швидше, це питання не аналізу, а також підготовки даних. Зазвичай дані все-таки неправильно зібрані, або їх недостатньо.

Наприклад, ми провели якусь міграцію, отримали у звіті success. Умовно було промигрировано 60 тис. об'єктів. Не знаючи специфіки цього бізнес-процесу, ми взяли і намалювали у звіті: «Все ок». А за фактом виявилося, що ці 60 тис. об'єктів видали якісь помилки. Все, що потрібно було зробити, це подивитися в потрібну табличку або в більш простому випадку зайти на особливу табу і подивитися, чи була операція виконана успішно. Але цього зроблено не було, в підсумку замір не вважається валідним, його не можна використовувати, щоб аналізувати швидкість роботи апликейшн.

JUG.ru: Синтетичні дані проти натуральних для навантажувального тестування: давайте визначимося з термінологією, що вважати синтетичними даними, а що — натуральними?

Андрій: Мені здається, тут доречна аналогія з автомобілем. Бувають повні натуральні дані (мінеральне масло), буває 100% синтетичне, а буває якийсь мікс. На тестуванні так само — дуже часто робиться якийсь мікс синтетичних і натуральних даних, тобто за основу беруться дані, які надає замовник (він, природно, маскує дані, які вважаються приватними і загрозливими його інтелектуальної власності), а на їх основі ми можемо генерувати додаткові об'єкти або збільшувати вкладеність існуючих. В залежності від того, наскільки багато ми згенерували, буде вище або нижче відсоток синтетики.

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

Про важливість натуральних даних
JUG.ru: Можна виділити ситуації, коли важливі саме натуральні дані?

Володимир: Я з таким не стикався. Але якщо розширити синтетику до зовнішніх систем, то тут можуть бути складності. Не завжди можна правильно сэмулировать зовнішню систему (якусь залізяку і т. п.). Витримати всі особливості — затримки за часом, кількістю одночасних з'єднань і т. п. — буває тяжко. Напевно, можна зробити якийсь емулятор, але найчастіше взяти готову зовнішню систему на порядок простіше, ніж намагатися оцінити ці моменти.

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

Володимир: Можна навести приклад: коли ми інтегруємося з мейнфрейм-системою, простіше взяти реально працюючий мейнфреймів (не production, а тестовий — його копію) і працювати з ним, ніж створювати купу стабів, які дані в них заганяти і т. д. Систему, написану, умовно кажучи, 20 років тому і більше, зараз вже ніхто не розуміє.

Переводячи питання в іншу площину — замінити синтетикою натуральні дані можна завжди, але є реальні обмеження, наприклад, терміни розробки та ресурси, які на це потрібні гроші і час). Та бувають випадки, коли взяти готову систему і її скопіювати простіше, ніж намагатися описати її логіку.

JUG.ru: Зустрічаються «неналежні» натуральні дані?

Володимир: Так. Є простий приклад, пов'язаний із пошуком.
Пошук — це одна з типових проблемних областей. Мати самі дані — це півбіди, треба знати, які варіанти пошуку будуть використовуватися. Зокрема, якщо ми будемо постійно шукати одне і те ж (наприклад, Джона Сміта), то у нас система до цього звикне, закеширует, і все буде нормально. Якщо ми будемо постійно рандомить, шукати взагалі різне, то у нас система буде трохи не в собі (ми можемо подати більш складну навантаження, ніж в бойовій системі). Всі ці тонкощі дуже впливають на результати виміру.

Треба відзначити, той факт, що ми скопіювали ті ж самі дані, зовсім не означає, що у нас навантажувальний тест видасть ту ж саму відповідь, що і production-система.

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

Якщо у нас реальна система працювала роками, дані там поступово створювалися і віддалялися, історичні записи в ній будуть лежати упереміш з новими. Після експорту-імпорту цього сервера може виявитися, що всі дані ляжуть поруч щільно і компактно. В результаті всі сценарії будуть працювати набагато краще, ніж вони реально працюють на production. Найбільш цього схильні, знову ж таки, сценарії пошуку, але ефект спостерігається і на інших сценаріях. Щоб позбавитися від цієї невідповідності, треба йти в бік повторення самого оточення: не просто копіювати самі дані, а повторювати байт в байт.

Якщо ми говоримо про базу даних Oracle, треба знімати клон файлів, а не самих даних. І у нас є випадки, коли тестове оточення у замовника розгорталося з клону бази даних — не на рівні самих даних, а на рівні бази — саме для того, щоб повторювати ці сценарії по навантаженню тестування.

JUG.ru: Як перевірити «якість» натуральних даних? Тут необхідно якесь чуття?

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

Андрій: Від себе хочу додати, що натуральні дані — це дані, які взяті в певний момент часу. І вони можуть протухати.
Є відомий проект, в якому я пропрацював майже 2 роки. І ми натуральні дані брали від 2008 і 2007 року. За цей час ці дані стали не актуальними. Але оскільки іншого способу не було і немає до цих пір, ми ці натуральні дані використовуємо, щоб генерувати більш актуальну синтетику.

JUG.ru: З якими проблемами доводиться стикатися при використанні копії корпоративних даних в якості основи для «натуральних» тестів?

Андрій: В першу чергу, ці дані, як-то прив'язуються до існуючим користувачам. А ці користувачі мають ID в інших системах, що не збігаються з ID в нашій «синтетиці».

Володимир: Перший момент — коли реальному користувачеві приходить email-повідомлення про тестовому дії. Ми беремо копію реальних даних з production, на ній проводимо тести — припустимо, підключення і відключення інтернету. І в цей момент користувачеві йде оповіщення про те, що у вас підключився / відключився інтернет.

Другий момент — при використанні реальних даних залишається занадто багато зав'язок на зовнішні системи. Наприклад, щоб правильно виконати підключення / відключення інтернету, потрібно мати інформацію про те, який тарифний план був у користувача і т. п. Вся ця інформація може зберігатися в інших системах. Тобто може виявитися, що доведеться довго готувати стаби, які будуть вміти розумно відповідати на наші запити, щоб правильно протестувати функціонал.

JUG.ru: Частина подібних проблем вирішується деперсоналізацією. Чи стикалися ви з впливом на результат тестування перетворень в ході деперсоналізації натуральних даних? Важлива і потрібна деперсоналізація взагалі?

Володимир: Від неї, напевно, нікуди не дітися. Як у будь-якому разі з даними, які не можна показувати — тут просто потрібно акуратно підходити до питання. Що це означає? Якщо ми просто візьмемо і замінимо всі імена Джон Сміт, що у нас відвалиться сценарій пошуку. Система буде постійно видавати замість однієї знайденої рядка мільйони. Якщо ж ми хочемо замінити всі імена на рандомные, це доведеться робити акуратно — не одне і те ж ім'я замінити по-різному в різних місцях. Якщо у нас ім'я фігурує в коментарі до договору, де-то в полях first name / full name, треба робити так, щоб ці зміни виявилися синхронними. У реальних системах дублювання даних досить багато, відповідно, коли ми робимо деперсоналізацію, їх треба акуратно підміняти, інакше у нас якісь сценарії просто не будуть працювати.

Про складнощі поєднання натуральних і синтетичних даних
JUG.ru: З якими труднощами можна зіткнутися при суміщенні натуральних і синтетичних даних? Існує якийсь загальний підхід для їх вирішення?

Андрій: Я б виділив ось які моменти.

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

Але така ситуація у нас досить рідкісна. Як правило, об'єкти мають дуже складні зав'язки і вкладеність. Уявімо собі який-небудь регіон (наприклад, Північно-Західний). В цьому регіоні є натуральні дані, наприклад, є 500 компаній. А нам потрібно для тіста 5 мільйонів компаній. І ми клонируем ці компанії або просто генера нові на основі нашого розуміння, як це повинно бути. На жаль, ми не можемо генерувати їх з тією ж ступенем вкладеності, з якого вони є. Ці 500 компаній реально важкі — у них є контракти, якісь проводки, офіси, клієнти та документообіг. А ми генеруємо тільки, умовно кажучи, ідентифікатори — базові об'єкти, які потрібні для тих кейсів, де це буде використовуватися. Але чорт його знає, які там кейси? Тобто ми можемо згенерувати синтетику, яка не дуже допомагає нам для тестів.

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

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

JUG.ru: З якими поширеними помилками вам доводилося стикатися при генерації синтетичних даних?

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

Володимир: Хочу доповнити, що в нашому випадку одні і ті ж дані підходили під велику кількість сценаріїв.

Якщо у нас для системи, наприклад потрібен мільйон клієнтів. І нам потрібно підключати інтернет / відключати інтернет. Ми не можемо зробити мільйон клієнтів для підключення до інтернету і мільйон для відключення (а потім на одних тестувати підключення, а на інших підключення). Якщо ми так зробимо, у нас база даних за своїми обсягами відразу піде в небеса, і тестувати ми будемо зовсім не те. Тому коли ми готуємо якусь синтетику, вона повинна пройти не просто один сценарій, а стільки сценаріїв, скільки буде потрібно, тобто об'єкти там повинні бути якимось чином правильно взаємопов'язані. Це перший момент.

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

JUG.ru: Це відсилання до того, що можна використовувати клон?

Володимир: Використовувати клон — це завжди добре. Але є підхід, що з цим робити. Наприклад, непоганий варіант — це використовувати наявний функціонал для створення самих даних. Якщо у нас є в системі функціонал для створення замовників та їх зміни/ видалення, то можна запису через цей функціонал створювати (щоб вони не одним SQL-запиту в базу містилися).



Якщо вам цікава тематика тестування, запрошуємо вас відвідати кнференцию Гейзенбаг, яка відбудеться 10 грудня в готелі «Radisson Слов'янська». Зареєструватися можна вже зараз.

Теми доповідей:

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.