Pairwise testing: якого біса воно нам не допомогло

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт, шановні колеги. На звʼязку Володимир Поздняков, QA-інженер з багаторічним стажем роботи. Маю за плечима чималу купу цікавих і складних проєктів, на яких успішно реалізовував всі свої навички, тож за якість цих проєктів мені не соромно.

Після прелюдій з розборами технік аналізу Класів еквівалентності та Граничних значень, настав-таки час поговорити про таку ж відому, як і загадкову техніку попарного тестування, або ж Pairwise Testing.

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

Що ж таке Pairwise Testing

Я: То що, ти справді вважаєш, що попарне тестування — це «Золотий Ґрааль» технік тест-дизайну?

Легковайті Тестущенко: Авжеж! Ти просто вдумайся: використовуючи цю техніку, ми можемо заощадити собі силу-силенну часу, сил та грошей. Це ж офігенно, коли ти можеш умовні 1000 тестів скоротити до 100, а то й до 10, і бути впевненим, що ефективність тестування водночас не впаде. Ну класно ж! Невже ти зі мною не згоден?

Я: Так-то воно так, але є але 😀

Легковайті Тестущенко: Я вже навіть не питаю... Ну що там знову?

Я: Ну не бурчи. Нумо розберемось. Почнімо з основи. Що воно за техніка така, зможеш пояснити?

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

Я: Так. Усе правильно.

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

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

Ось тобі й приклад із системою, яка може приймати три вхідних параметри, кожен з яких може бути двома певними значеннями:

Я: Ого, ти мене вражаєш. Молодець, дуже все влучно сказано та показано.

Легковайті Тестущенко: Почекай, це ще не все. Візьми майже будь-яку книжку з тестування, запитай будь-якого тестувальника, навіть початківця, і він тобі скаже, що Pairwise Testing — це «бест практис» технік тестування. Це суперпотужна і ефективна техніка. Ти ж не будеш із цим сперечатись?

Я: Ні, все так і є.

Легковайті Тестущенко: Ага! Ну що? Як я тебе переконав!

Я: Усе те, що ти сказав — правильно та справедливо. Але нумо я поставлю тобі декілька питань.

Легковайті Тестущенко: Валяй.

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

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

  • потужність (1,5 кВт, 2,0 кВт, 2,5 кВт, 3 кВт);
  • термін оренди (три місяці, шість місяців, дев’ять місяців);
  • захист (водозахист, жаростійкість, агресивні умови);
  • умови оплати (щотижня, помісячно, повна вартість).

Що скажеш? Чи доречна тут техніка попарного тестування?

Легковайті Тестущенко: Однозначно! У нас є чотири параметри, які впливають на кінцевий результат. Комбінаторно, якщо порахувати вичерпну кількість комбінацій, матимемо: 4 * 3 * 3 * 3 = 108. Отже маємо 108 можливих комбінацій. А застосовуючи техніку попарного тестування, ми скорочуємо цю кількість до 12 варіантів.

Я: Правильно! Розкажеш, як ти так швидко прикинув, скільки буде скорочених варіантів?

Легковайті Тестущенко: Ага. Взагалі для остаточного обчислення комбінацій я користуюсь програмним забезпеченням, яке в цьому допомагає (наприклад: CLI утиліта AllPairs або вебрішення Pairwise Pict Online), але є один лайфхак, як орієнтовно їх швидко порахувати: треба взяти кількість значень з двох найдовших стовпчиків і перемножити їх. У нашому випадку це перший (чотири значення) та будь-який інший (бо всі вони мають по три значення). Отже 4 * 3 = 12 кейсів.

Я: Ок.

Легковайті Тестущенко: Бачиш, яка все ж таки ефективна техніка?

Я: А що, як я тобі скажу, що достатньо виконати чотири тестові сценарії, а не 12?

Легковайті Тестущенко: Як це? Ти ж сам бачиш, що 108 і так скоротили до 12. Ні, не може бути!

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

Q = k * P * T * S * C (грн/місяць)

де k — націнка компанії (стале значення 1,25);
Р — амортизація обладнання залежно від потужності (1500, 2000, 2500, 3000 грн відповідно);
Т — знижка на довготривалість оренди (1, 0,98, 0,95 відповідно);
S — коефіцієнт на додатковий захист (1,05, 1,08, 1,12 відповідно);
С — знижка на метод розрахунку (1, 0,95, 0,9 відповідно).

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

Легковайті Тестущенко: Оу...

Я: Отож бо й воно! Pairwise testing — дуже класна та потужна техніка тест-дизайну, але треба чітко розуміти, що все залежить від контексту. Кожного разу, коли є питання: «Які тести потрібно проводити?», «Які техніки тест-дизайну доцільні?», треба зважати на контекст.

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

Та про те, що треба розуміти контекст і оцінювати залежності, чомусь постійно забувають і пхають цю техніку просто тому, що вона ж «бест практис»...

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

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

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

Я: Круто. Радий, що зміг допомогти тобі бути більш професійним спеціалістом.

Легковайті Тестущенко: Ти на кожну техніку тестування знайдеш якийсь підступ. То що, марно їх використовувати?..

Я: Ні. Я цього не казав.

Замість висновку

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

Тож вмикайте голову, не беріть на віру «бест практис» мантру, а перевіряйте, аналізуйте і ставайте кращими у своїй сфері!


P.S. До вашого відома: ось цікава інформація стосовно «бест практис» та «Золотого Ґрааля» — техніки попарного тестування.

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

Тобто наш найкращий метод тестування працює не краще, ніж рандомний відбір**.

От і думайте тепер...



* P. J. Schroeder, P. Bolaki, and V. Gopu, «Comparing the Fault Detection Effectiveness of N-way and Random Test Suites,» in Proc. of the Int’l Symposium on Empirical Software Engineering. Redondo Beach, CA, 2004.

** D. Hamlet and R. Taylor, «Partition Testing Does Not Inspire Confidence,» IEEE Transactions on Software Engineering, vol. 19, no. 3, pp. 202-213, 1990.

👍ПодобаєтьсяСподобалось22
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

Підписатись на коментарі