Пов'язані із змінами види тестування. Smoke-тестування Вашої програми: Посібник для гуманітаріїв та співзасновників
Переклад розбавлений роздумами та доповненнями автора зі свого досвіду
Про що це все
Будучи інженером з тестування, ви, ймовірно, чули про такі види тестування як «димове» (smoke), «санітарне тестування» (sanity), «ре-тест» та регресійне тестування. Цілком можливо, що багато з цих видів використовуються вами на щоденній основі.У цій статті я хотів би внести ясність і пояснити різницю між цими видами тестування та спробувати розібратися, провести межі (хоч і умовні), де закінчується один вид тестування, і починається інший.
Для новачків у тестуванні (і навіть досвідчених тестувальників) поділ цих понять може бути скрутним. І справді, як відрізнити де починається саніті-тестування та закінчується smoke? Наскільки сильно нам треба обмежити перевірку частини функціональності системи чи її компонентів, щоб назвати це «димовим» тестуванням? Чи є введення логіна/пароля в форму користувача входу на сайт димовим тестом, або сам факт її появи на сторінці сайту вже є пройденим тестом?
Строго кажучи, ви все одно зможете проводити тестування, навіть при тому, що не зможете точно сказати, в чому ж різниця. Можна навіть не замислюватися над розмежуванням, яким саме видом тестування ви зараз зайняті. Але все ж, щоб рости над собою у професійному сенсі, потрібно знати, що ви робите, навіщо, і наскільки правильно ви це робите.
Лікнеп
Нижче наведено короткі визначеннявидів тестування, які ми сьогодні порівнюємо:- Димові тести: виконуються кожного разу, коли ми отримуємо новий білд (версію), проекту (системи) на тестування, вважаючи її відносно нестабільною. Нам потрібно переконатися, що критично важливі функції AUT (Application Under Test) працюють відповідно до очікувань. Ідея даного виду тестування полягає в тому, щоб виявити серйозні проблеми якомога раніше, і відхилити цей білд (повернути на доопрацювання) на ранньому етапі тестування, щоб не заглиблюватися в довгі та складні тести, не витрачаючи тим самим час на заздалегідь браковане програмне забезпечення.
- Санітарне тестування: використовується щоразу, коли ми отримуємо відносно стабільний білд, щоб визначити працездатність в деталях. Іншими словами, тут відбувається валідація того, що важливі частини функціональності системи працюють згідно з вимогами на низькому рівні.
- Ре-тест: проводиться у випадку, якщо фіча/функціональність вже мала дефекти, і ці дефекти були нещодавно виправлені.
- Регресійні тести: власне те, що займає левову часткучасу та навіщо існує автоматизація тестування. Проводиться регресійне тестування AUT тоді, коли потрібно переконатися, що нові (додані) функції програми / виправлені дефекти не вплинули на поточну, вже існуючу функціональність, що працювала (і протестовану) раніше.
| Димові (Smoke) | Саніті (Sanity) | Регресійні (Regression) | Ре-тест (Re-test) |
|---|---|---|---|
| Виконуються з метою перевірити, що критично важливі функціональні частини AUT працюють як належить | Націлено на встановлення факту того, що певні частини AUT так само працюють як належить після мінорних змін або виправлень багів | Підтверджують, що свіжі зміни в коді або додатку в цілому не вплинули на вже існуючу функціональність/набір функцій. | Перевіряє ще раз і підтверджує факт того, що раніше завалені тест-кейси проходять після того, як дефекти виправлені |
| Мета - перевірити «стабільність» системи в цілому, щоб дати зелене світло проведенню ретельнішого тестування. | Метою є перевірити загальний стан системи в деталях, щоб почати ретельніше тестування. | Мета - переконатися, що свіжі зміни в коді не надали побічних ефектівна усталену працюючу функціональність | Ре-тест перевіряє, що дефект виправлено |
| Перевірка дефектів не є метою Smoke | Перевірка дефектів не є метою Sanity | Перевірка дефектів не є метою Regression | Факт того, що дефект виправлений підтверджує Re-Test |
| Димове тестування виконується передрегресійним | Санітарне тестування виконується передрегресійним та після smoke-тестів | Проводиться на підставі вимог проекту та доступності ресурсів (закривається автотестами), «регрес» може проводитись у паралелі з ре-тестами | - Ре-тест виконується перед sanity-тестуванням - Так само, пріоритет ре-тесту вищий регресійних перевіроктому має виконуватися перед ними |
| Може виконуватись автоматизовано або вручну | Найчастіше виконується вручну | Найкращий привід для автоматизації цього виду тестування, т.к. ручне може бути вкрай витратним за ресурсами чи часом | Не піддається автоматизації |
| Є підмножиною регресійного тестування | Підмножина приймального тестування | Виконується за будь-якої модифікації чи змін у вже існуючому проекті | Ре-тест проводиться на виправленій збірці з використанням тих самих даних, на тому ж оточенні, але з різним набором вхідних даних |
| Тест-кейси є частиною регресійних тест-кейсів, але покривають вкрай критичну функціональність. | Санітарне може виконуватися без тест-кейсів, але знання системи, що тестується, обов'язково | Тест-кейси регресійного тестування можуть бути отримані з функціональних вимог або специфікацій, мануалів, і проводяться незалежно від того, що виправили розробники | Використовується той же тест-кейс, який виявив дефект |
Ну, а по суті?
Наведу приклад розмежування понять на поточному проекті.Приклад: у нас є веб-сервіс з інтерфейсом користувача і RESTful API. Будучи тестувальниками, ми знаємо:
- Що має 10 точок входу, для простоти, в нашому випадку розміщених на одному IP
- Ми знаємо, всі вони приймають GET-запит на вхід, повертаючи будь-які дані у форматі json.
- Виконавши один простий GET-запит до однієї з цих точок входу і отримавши відповідь у форматі json, ми вже переконуємося, що димне тестування пройдено.
Якщо одна з цих точок входу так само повертає дані з БД, тоді як перша - ні, потрібно додатково виконати ще один запит, щоб переконатися, що додаток
чітко обробляє запити до бази. І на цьому «димний» тест закінчено.Тобто ми виконали запит - від сервісу надійшла відповідь, і він не «задимився», тобто не повернув помилку 4хх або 5хх, і щось невиразне замість json. На цьому можна сказати, що «димний» тест пройдено. Для перевірки того, що працює так само і UI, досить просто один раз відкрити сторінку в браузері.
- Санітарне тестування в даному випадку складатиметься з виконання запиту до всіх 10 точок входу в api, звіркою отриманого json з очікуваним, а також наявністю необхідних даних у ньому.
- Регресійні тести будуть складатися з smoke + sanity + UI, що виконуються разом в одній купі. Мета: перевірити, що додавання 11-ої точки входу не поламало, наприклад, відновлення пароля.
- Ре-тест у даному прикладіце точкова перевірка що, наприклад, точка входу, що зламалася, в api в наступному білді відпрацьовує як замислювалося.
Підіб'ємо підсумок
Сподіваюся, що після читання цієї статті, у вас з'явиться ясність у визначенні який вид тестування ви використовуєте на якомусь етапі, і в чому різниця між цими видами тестування. Як і було згадано спочатку, межа між цими поняттями є досить умовною і залишається на ваш розсуд у рамках проекту.UPD:
Часто «тестування узгодженості» або «тестуванням на осудність» називають терміном «санітарне тестування». Думаю, що це пішло через фонетичні властивості англійського слова sanity, схожого за звучанням із чимось «санітарним». Google транслейт вносить ясність. В інтернеті зустрічаються обидва варіанти. Щодо цієї статті прошу вважати «санітарне» тестування як «тестування на узгодженість».
Дякую за наведення
Якщо Ви хочете створити просту комп'ютерну програму, Що складається з одного файлу, Вам просто необхідно зібрати і зв'язати весь написаний Вами код в цей файл. На звичайнісінькому проекті, яким займається команда розробників, існують сотні, навіть тисячі файлів. Це «сприяє» тому, що процес створення програми, що здійснюється, стає все більш складним і трудомістким: ви повинні «збирати» програму з різних компонентів.
Практика, що застосовується, наприклад, у Microsoft та деяких інших компаніях, що займаються розробкою ПЗ, полягає в щоденному складанні (білдуванні) програми, яка доповнюється димовим тестуванням. Щодня, після того, як кожен файл зібраний (збілдований, побудований), пов'язаний (слінкований), і об'єднаний у програму, що виконується, сама програма піддається досить простому набору тестів, мета яких полягає в тому, щоб побачити, «димить» чи програма під час роботи. Ці тести і називаються димовими (від англ. Smoke – дим). Найчастіше цей процес досить добре автоматизований (або має бути таким).
ПЕРЕВАГИ. Цей простий процес забезпечує кілька суттєвих переваг.
Мінімізація ризику під час інтеграції
Один із найістотніших ризиків, з яким стикається команда розробників, полягає в тому, що самі розробники працюють із кодом окремо, незалежно один від одного, внаслідок чого складна програма не працює, як очікується при складанні напрацьованого коду. Залежно від того, коли була виявлена несумісність у проекті, налагодження програми може відбуватися довше, ніж за більш ранньої інтеграції, особливо у разі зміни інтерфейсу програми або після імплементації серйозних правок основних частин програми.
Щоденне складання та прогін димових тестів дає можливість знизити ризик інтеграційних помилок, вчасно реагувати на них і не допускати їх накопичення.
Зниження ризику низької якості програмного продукту
Низька якість продукту залежить від невдач і проблем при інтеграції. Щоденне прогонування мінімального набору димових тестів не дає помилок і проблем взяти гору на проекті. Якщо ви довели проект до стабільного стану разів, він залишатиметься стабільним завжди. Цим ви ніколи не допустите зниження якості до рівня, на якому виникають помилки.
Допомога у діагностиці помилок
Якщо одного дня продукт не зібрався (зібрався з помилками), то за допомогою щоденного складання та прогону набору димових тестів набагато простіше знайти причину проблеми. Працюючий продукт учора і не працюючий сьогодні - це явний натяк на те, що щось не ладне сталося між двома збираннями.
Поліпшення морального духу
Якщо продукт працює і з кожним днем обростає все більш новими якостями та функціями, моральний дух розробників, за ідеєю, повинен зростати і абсолютно не важливо, що саме повинен робити цей продукт. Розробнику завжди приємно спостерігати за своїм діючим, що працює, навіть якщо продукт виводить на екран прямокутник:)
Використання щоденного білдування та димових тестів
Ось кілька подробиць цього принципу.
Щоденне складання програми
Фундаментальною частиною щоденного складання є складання тієї частини, що була зроблена останньою. Джим Маккарті (Jim McCarthy) у журналі Dynamics of Software Development (Microsoft Press, 1995) назвав щоденне білдування проекту його серцебиттям. Якщо серцебиття немає – проекту немає, він мертвий. Менш образно щоденне білдування описали Майкл Касамано (Michael Cusumano) та Річард Селбі (Richard W. Selby), назвавши його синхронізуючим імпульсом проекту (Microsoft Secrets, The Free Press, 1995). Кожен розробник пише код по-своєму і він, код, може виходити за загальноприйняті на проекті рамки - це нормально, але при кожній дії синхронізуючого імпульсу код повертається до стандарту. Наполягаючи на веденні розробки з використанням імпульсу синхронізації постійно, Ви перешкоджаєте виходу проекту із синхронізації повністю.
У деяких компаніях прийнято збирати проект не щодня, а щотижня. Ця система хибна, т.к. у разі «поломки» у проекті на поточному тижні, може пройти ще кілька тижнів до наступного вдалого складання. У такому разі компанія втрачає всі переваги системи щоденного складання проекту.
Перевірка на невдале складання
У разі щоденного складання проекту мається на увазі, що проект має працювати. Однак, якщо ж проект виявляється не робочим, то його ремонт стає завданням з пріоритетом 1.
На кожному проекті є свій стандарт та ознака того, що називається «поломка при складанні». Цей стандарт повинен задавати рівень якості, який є достатнім для того, щоб відстежувати незначні дефекти і не зважати на дефекти, що «блокують» проект.
Хорошим збиранням є та, при якій як мінімум:
- успішно компілюються всі файли, бібліотеки та інші компоненти;
- посилання на всі файли, бібліотеки та інші компоненти є дійсними;
- не містяться жодних стійких системних, що виключають можливість правильної роботиприкладної програми, що блокують помилок;
- всі димові випробування проходять.
Щоденні димові тести
Димові тести мають виконуватися на всьому проекті від початку до кінця. Вони не повинні бути вичерпними та всебічніми, але повинні містити перевірку всіх основних функцій. Димове тестування має бути досить глибоким, щоб, у разі успішного їх проходження, можна було назвати проект стабільним і назвати його таким, що може піддаватися глибшому тестуванню.
Сенс щоденного складання втрачається без димового тестування. Цей процес стоїть на варті якості продукту та не допускає жодних інтеграційних проблем. Без цього процес щоденного складання є марною тратою часу, мета якої – перевірка компіляції.
Димове тестування має розвиватися лише на рівні з проектом. На початку димові тести перевірятимуть щось просте, наприклад, чи може проект видавати повідомлення «Hello, World!». З розвитком системи димові тести стають глибшими. Час, який витрачається на перші димові тести, обчислюється кількома секундами, проте зі зростанням системи зростає кількість необхідного для димового тестування часу. Наприкінці проекту димове тестуванняможе тривати протягом годин.
Визначення групи збирання
На більшості проектів є певний співробітник, відповідальний за перевірку щоденного складання системи та виконання димових тестів. Ця робота є частиною обов'язків даного співробітника, але на великих проектахтаких співробітників може бути більше і така робота є основним їх обов'язком. Наприклад, у групі збирання проекту Windows NT 3.0 було чотири особи (Pascal Zachary, Showstopper!, The Free Press, 1994).
Додавайте ревізію до складання тільки якщо це має сенс
Зазвичай розробники окремо пишуть код досить повільно, щоб можна було додавати значні зміни до системи щодня. Вони повинні працювати над великою частиною коду та інтегрувати його в систему раз на кілька днів.
|
Введіть систему штрафів за зрив випуску чергового збирання (випуск не робочого складання). |
На більшості проектів є система штрафів за зрив випуску чергового збирання. На початку проекту варто чітко дати зрозуміти, що збереження робочого проекту є завданням найвищого пріоритету. Зрив випуску чергової збірки може бути винятком, але ні як не правилом. Наполягайте на тому, щоб розробники залишали всі справи доти, доки система знову не запрацює. У разі частого зриву складання (випуску не робочого складання) досить важко повернути проект у нормальне русло.
Незначні штрафи наголошують на високому ступені необхідності стежити за якістю складання системи. На деяких проектах розробникам, з вини яких збірка «падає», видають льодяники за випуск збірки, що не працює. На дверях кабінету такого розробника висить відповідна вивіска до тих пір, поки він не полагодить складання (за умови, що у розробників окремі кабінети). На інших проектах винні розробники повинні носити штучні козлячі роги або вносити певну суму в фонд морального духу (приклади взяті з історії реальних компаній).
Але на деяких проектах запроваджуються більш серйозні штрафні санкції. Наприклад, розробники компанії Microsoft, які перебувають у проектах із високим пріоритетом (Windows NT, Windows 95, Excel), носили пейджери і, у разі виявлення перевірки, вони мали прибути працювати. Навіть якщо поломка або помилка були виявлені о 3 ранку.
Збирайте систему та «димайте» її навіть під тиском
Коли тиск графіка випуску проекту посилюється, робота щодо щоденної перевірки складання системи може здаватися безглуздою витрачанням часу. Однак, це не так. У стресових ситуаціях розробники часто припускаються помилок. Вони відчувають такий тиск необхідності випускати імплементації, якого в звичайних умовахпросто ні. Вони перевіряють свій код unit-тестами значно менш уважно, ніж зазвичай. У таких ситуаціях код прагне стану ентропії набагато швидше ніж менш стресових ситуаціях.
Хто виграє від цього процесу? Деякі розробники протестують проти щоденних збірок, обґрунтовуючи свої протести непрактичністю цього заняття та його тимчасовими витратами. Але все складні системиостаннього часу піддавалися щоденним складанням та прогону димових тестів. До моменту свого випуску Microsoft Windows NT 3.0 містила в 40 000 файлах 5,6 мільйонів рядків. Повне складаннязаймала 19 годин та виконувалася на кількох комп'ютерах. Незважаючи на це, розробники примудрялися щоденно збирати систему. Будучи професійною командою, група розробників NT своїм успіхом багато в чому зобов'язана щоденному складання. Ті розробники, які працюють на менш складних проектахі тому, не користуються перевагами процесу щоденної збірки, повинні замислитися з того, щоб придумати собі якісь розумні пояснення.
Прості помилки можуть бути фатальними для вашого сайту – особливо якщо Ви – SaaS (eng. Software as a Service) компанія, як ми. Якщо користувач заходить на Ваш сайт і не може впоратися із простим завданням, таким як зареєструватися або скинути свій забутий пароль, Ви ризикуєте втратити цього користувача назавжди.
Ми випробували це на власній шкурі. Безумовно, мати своїх людей у команді, які тестують додаток та шукають баги – це важливо, але не завжди доречно чи недостатньо ретельно. У цій статті ми хочемо представити Вам, гуманітаріям, світ smoke-тестів.
Якщо все ж таки у Вас залишаться питання - заповнити прогалини ви зможете, відвідавши
Smoke-тестування спочатку було придумано, щоб пояснити як інженери-електротехніки перевіряли чи працює їхній прилад — включали його і якщо дим йшов…
Зачекайте, як це може бути застосовано до програм?
Важливість (і рентабельність) smoke-тестів, як правило, невідома для менеджерів-гуманітаріїв та співзасновників. Систематичні smoke-тести можуть розглядатися як невід'ємна частинадля запобігання зростанню ймовірності злому. Вони мінімізують ймовірність того, що у Вашому веб-додатку або додатку для телефону відбудеться збій - і як ми всі знаємо, тільки одна невдача і ви можете втратити клієнта назавжди.
Це вступне керівництво про те, що це таке, як це може бути реалізовано, які ресурси використовуються для його проведення та приклади, що направляють читачів.
Smoke тести створені для того, щоб перевірити основну функціональність і повинні бути невід'ємною частиною Вашого процесу тестування. Вони можуть включати щось просте, на кшталт «Я можу зареєструватися?».
Smoke-тестування допомагає переконатися, що жодна з основних та очевидних невдач не залишена на волю випадку. Не слід проводити більш глибокий тест, доки ви не виконали smoke-тести на 100%, тому що вони очищають програмне забезпеченнявід фундаментальних помилок
Крок 1: Вирішіть, що треба тестувати
Визначте, що Ваша програма прагне досягти. Якими є найбільш очевидні «дитячі» кроки, які необхідні, щоб до нього потрапити? Які мінімальні життєво важливі вимогиі в якій логічній послідовності Ви їх перерахуєте?
Створіть набір тестів. Набір тестів - це згрупована сукупність тест-кейсів (тестових випадків), пов'язана певним чином (наприклад, за функціональністю).
Smoke-тестування не включатиме змінні або питання виду «що якщо?». Воно передбачає лише відповіді так/ні, але перш ніж переходити до детальнішого тестування, всі тест-кейси повинні бути пройдені з позитивним результатом.
Давайте візьмемо для прикладу створення інтерактивного форуму. Для того, щоб він працював, я повинен:
- зареєструватись.
- створити Ім'я користувача.
- завантажити фото на аватарку
- писати повідомлення.
- відповідати на повідомлення.
Крок 2: Записуємо результати до таблиці
Зображення вище – приклад від нашої команди. Ви можете знайти шаблон. Це необхідно для того, щоб зберегти записи того, що у нас працює, а що ні, — базова організація заощадить купу часу надалі. Ми розділили наші результати на пройдено, частково та провалено.
- Пройдено: все працює ідеально.
- Частково: спочатку ви можете не розуміти, що деякі дії можуть бути підрозділені, і тому одна частина працює, а інша — ні.
- Провалено: не працює.
Ми описали точні кроки, які ми хотіли відтворити, а потім у наступній графі додали короткий описте, що ми очікуємо на виході. Приклад:
Крок 3: Автоматизуємо smoke-тести
Дуже важливо не приймати за аксіому те, що якщо будь-яка дія була пройдена один раз, вона завжди буде з позитивним результатом. Smoke-тести дозволяють постійно перевіряти, що основні функції не постраждали з часом або не були поламані протягом тривалого періоду.
Чи не припиняй smoke-тестування. Ніколи.
Коли Ваш набір тест-кейсів для smoke-тестування завершується з успішним результатом 100%, подумайте про їхню автоматизацію. Частота проведення smoke-тестів, що рекомендується, — щодня, якщо Ваша компанія займається розробкою щодня.
Мінімальна необхідність - проводіть прогін smoke-тестів перед кожним релізом та після кожного патчу.
Емпіричне правило для smoke-тесту:
- Мінімальний час: 30 хвилин.
- Максимальний час: 60 хв.
Надалі автоматизація smoke-тестів економить час, але при прогоні одних і тих же тестів знову і знову людське око може перестати помічати деталі, а машина немає.
Smoke testing (зустрічаються назви intake test, build verification test) - тестування, що проводиться на початковому етапі(наприклад після нового білду) і в першу чергу спрямоване на перевірку готовності розробленого продукту до проведення розширеного тестування, визначення загального стану якості продукту.
Це короткий цикл тестів, що підтверджує (заперечує) факт того, що програма стартує і виконує свої основні функції. Даний тип тестування дозволяє на початковому етапі виявити основні критичні дефекти, що швидко знаходяться. Виходячи з того, що дані перевірки практично завжди однакові і рідко зазнають змін, доцільно їх автоматизувати.
Приклад smoke testing:
Якщо приміром брати проект DI Tool STAR, то даний типтестування буде включати перевірку наступних функціональностей:
Login form (логін з валідними даними)
Log out form (клік по кнопці)
Property selection (перевірка, що функціональність є і вона працює)
Property Lists (що вони є, без збереження/видалення)
Proceed to STAR
Menu (клік)
Views switching
Drawer (перемикання табів, перемикання кнопок усередині табів)
Export (спрацьовування кнопки)
Header property selector
Favorites (перевірка що функціональність є і вона працює)
Потрібно визначити які завдання потрібно досягти завдяки нашому додатку, які очевидні кроки для досягнення поставленого завдання, яких важливих вимог ми повинні дотримуватись і в якій послідовності.
Для цього створюємо набір тестів. Набір тестів - це згрупована сукупність тестових випадків, пов'язана певним чином (наприклад, за функціональністю).
Smoke-тести створені для того, щоб перевірити основну функціональність і повинні бути невід'ємною частиною тестування. Вони можуть містити щось просте, на кшталт “Чи можу я зареєструватися?”. Smoke-тестування передбачає відповіді ТАК/НІ та всі тест-кейси повинні бути пройдені з позитивним результатом.
Smoke test повинні бути швидкими та легковажними, для того, щоб їх можна було запускати часто. Залежно від специфіки проекту, smoke test можна пройти як за кілька хвилин, так і за кілька годин.
Варто розуміти, що цей тип тестування є видом тестування продукту за глибиною, а не просто видом тестових випробувань. Як говорилося вище, даний тип тестування визначає, чи придатний продукт для подальшого, більш повного тестування. Якщо він не проходить smoke testing — продукт необхідно відправити на доопрацювання.
Обов'язково потрібно записувати результати проходження тесту. Це необхідно для того, щоб зберегти запис того, що працює, а що ні. Можна розділити результати на пройдено та провалено.
Пройдено: все добре працює.
Провалено: не працює.
Привіт, Хабре! Якось на нашому внутрішньому семінарі мій керівник – голова відділу тестування – розпочав свою промову зі слів «тестування не потрібне». У залі всі притихли, дехто навіть намагався впасти зі стільців. Він продовжив свою думку: без тестування цілком можливо створити складний та дорогий проект. І, швидше за все, він працюватиме. Але уявіть, наскільки впевненіше ви почуватиметеся, знаючи, що продукт працює як треба.
У Badoo релізи відбуваються досить часто. Наприклад, серверна частина нарівні з desktop web релізується двічі на день. Так що ми не з чуток знаємо, що складне та повільне тестування – камінь спотикання розробки. Швидке тестування – це щастя. Отже, сьогодні я розповім про те, як у компанії Badoo влаштовано smoke-тестування.
Що таке smoke-тестування
Перше своє застосування цей термін отримав у пічників, які, зібравши піч, закривали всі заглушки, затоплювали її і дивилися, щоб дим йшов лише з належних місць. ВікіпедіяВ оригінальному застосуванні smoke-тестування призначене для перевірки найпростіших і очевидних кейсів, без якої будь-який інший вид тестування буде невиправдано зайвим.
Давайте розглянемо найпростіший приклад. Передпродакшн нашого додатка знаходиться за адресою bryak.com (будь-які збіги з реальними сайтами випадкові). Ми підготували та залили туди новий реліз для тестування. Що варто перевірити насамперед? Я б почав з перевірки того, що програма все ще відкривається. Якщо web-сервер нам відповідає «200», то все добре і можна приступати до перевірки функціоналу.
Як автоматизувати таку перевірку? В принципі, можна написати функціональний тест, який підніматиме браузер, відкриватиме потрібну сторінку і переконуватись, що вона відобразилася як треба. Проте, це рішення має низку мінусів. По-перше, це довго: процес запуску браузера займе більше часу, ніж перевірка. По-друге, це вимагає підтримки додаткової інфраструктури: задля такого простого тесту нам потрібно буде десь тримати сервер із браузерами. Висновок: треба вирішити задачу інакше.
Наш перший smoke-тест
У Badoo серверна частина написана здебільшого на PHP. Unit-тести зі зрозумілих причин пишуться на ньому ж. У нас уже є PHPUnit. Щоб не плодити технології без потреби, ми вирішили писати smoke-тести теж на PHP. Крім PHPUnit, нам буде потрібна клієнтська бібліотека роботи з URL (libcurl) та PHP extension для роботи з нею – cURL.По суті тести просто роблять потрібні нам запити на сервер і перевіряють відповіді. Все пов'язане з методом getCurlResponse() і кількох типах асертів.
Сам метод виглядає приблизно так:
Public function getCurlResponse($url, array $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ expected_response = '200 OK') ( $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) if ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data'])) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line)); ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy) ']); ) if (isset($params['user_agent']) && $params['user_agent']) ( $user_agent = $params['user_agent']; ) else ( $user_agent = USER_AGENT_DEFAULT; ) curl_setopt($ch, CURLOPT_USERAGENT, $user_agent); curl_setopt($ch, CURLOPT_AUTOREFERER, 1); $response = curl_exec($ch); $this->logActionToDB($url, $user_agent, $params); if ($follow_location) ( $this->assertTrue((bool)$response, "Empty response was received. Curl error: " . curl_error($ch) . ", errno: " . curl_errno($ch))); $this ->assertServerResponseCode($response, $expected_response); ) curl_close($ch); return $response; )
Сам метод вміє по заданому URL повертати відповідь сервера. На вхід приймає параметри, такі як cookies, headers, user agent та інші дані, необхідні формування запиту. Коли від сервера отримано, метод перевіряє, що код відповіді збігається з очікуваним. Якщо це не так, тест падає з помилкою, яка повідомляє про це. Це зроблено для того, щоб було простіше визначити причину падіння. Якщо тест впаде на якомусь асерті, повідомивши нам, що на сторінці немає якогось елемента, помилка буде менш інформативною, ніж повідомлення про те, що код відповіді, наприклад, «404» замість «200».
Коли запит надіслано та відповідь отримано, ми логуємо запит, щоб надалі за необхідності легко відтворити ланцюжок подій, якщо тест впаде або зламається. Я про це розповім нижче.
Найпростіший тест виглядає приблизно так:
Public function testStartPage() ( $url = 'bryak.com'; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Такий тест проходить менш ніж за секунду. За цей час ми перевірили, що стартова сторінкавідповідає «200» і на ній є елемент body. З тим самим успіхом ми можемо перевірити будь-яку кількість елементів на сторінці, тривалість тесту суттєво не зміниться.
Плюси таких тестів:
- швидкість - тест можна запускати так часто, як це потрібно. Наприклад, на кожну зміну коду;
- не вимагають спеціального софту та заліза для роботи;
- їх нескладно писати та підтримувати;
- вони стабільні.
Авторизація
Припустимо, що з моменту, як ми написали наш перший smoke-тест, минуло три дні. Зрозуміло, за цей час ми покрили всі неавторизовані сторінки, які тільки знайшли, тестами. Небагато посиділи, пораділи, але потім усвідомили, що все найважливіше в нашому проекті знаходиться за авторизацією. Як отримати можливість це теж тестувати?
Найпростіший варіант - авторизаційна cookie. Якщо додати її до запиту, сервер нас «дізнається». Таку cookie можна захардкодити в тесті, якщо її час життя досить великий, а можна отримувати автоматично, надсилаючи запити на сторінку авторизації. Давайте розглянемо другий варіант.
Нас цікавить форма, куди треба ввести логін та пароль користувача.
Відкриваємо цю сторінку у будь-якому браузері та відкриваємо інспектор. Вводимо дані користувача і зробимо форму.
В інспекторі з'явився запит, який треба імітувати в тесті. Можна подивитися, які дані, крім очевидних (логін та пароль), надсилаються на сервер. Для кожного проекту по-різному: це може бути remote token, дані будь-яких cookies, отриманих раніше, user agent і так далі. Кожен із цих параметрів доведеться попередньо отримати у тесті, перш ніж сформувати запит на авторизацію.
В інструментах розробника будь-якого браузера можна скопіювати запит, вибравши Copy as CURL. У такому вигляді команду можна вставити в консоль та розглядати там. Там її можна випробувати, змінивши або додавши параметри.
У відповідь на запит сервер поверне нам cookies, які ми будемо додавати в подальші запити, щоб тестувати авторизовані сторінки.
Оскільки авторизація – досить довгий процес, авторизаційну cookie я пропоную одержувати лише один раз для кожного користувача та зберігати десь. У нас, наприклад, такі cookies зберігаються у масиві. Ключем є логін користувача, а значенням – інформація про них. Якщо для наступного користувача ще немає ключа, авторизуємося. Якщо є – робимо запит, що цікавить нас, відразу.
Public function testAuthPage() ( $url = 'bryak.com'; $cookies = $this->getAuthCookies(' [email protected]', '12345'); $response = $this->getCurlResponse($url, ['cookies' => $cookies]); $this->assertHTMLPresent("
", $response, "Error: test cannot find body element on the page."); )Як ми бачимо, додався метод, який отримує авторизаційну cookie і просто додає її в подальший запит. Сам метод реалізується досить просто:
Public function getAuthCookies($email, $password) ( // check if cookie already has been got If (array_key_exist($email, self::$known_cookies)) ( return self::$known_cookies[$email]; ) $url = self::DOMAIN_STAGING '/auth_page_adds'; $post_data = ['email' => $email, 'password' => $password]; post_data]); $cookies = $this->parseCookiesFromResponse($response);
Метод спочатку перевіряє, чи є для даного e-mail (у вашому випадку це може бути логін або ще щось) вже отримана раніше авторизаційна cookie. Якщо є, він її повертає. Якщо ні, він запитує на авторизаційну сторінку (наприклад, bryak.com/auth_page_adds) з необхідними параметрами: e-mail і пароль користувача. У відповідь на цей запит сервер надсилає заголовки, серед яких є cookies, що нас цікавлять. Виглядає це приблизно так:
HTTP/1.1 200 OK Server: nginx Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: name=value; expires=Wed, 30-Nov-2016 10:06:24 GMT; Max-Age = -86400; path=/; domain=bryak.com
З цих заголовків нам за допомогою нескладного регулярного виразу треба отримати назву cookie та її значення (у нашому прикладі це name = value). У нас метод, який парсить відповідь, виглядає так:
$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $response, $mch1), " Cannot get "cookies" from server response: ". $response);
Після того, як cookies отримані, ми можемо сміливо додавати їх до будь-якого запиту, щоб зробити його авторизованим.
Розбір тестів, що падають
Зі сказаного вище, такий тест – це набір запитів до серверу. Робимо запит, здійснюємо маніпуляцію з відповіддю, робимо наступний запит тощо. В голову закрадається думка: якщо такий тест впаде на десятому запиті, може виявитися непросто розібратися через його падіння. Як спростити собі життя?Насамперед я хотів би порадити максимально атомізувати тести. Не варто в одному тесті перевіряти 50 різних кейсів. Чим тест простіше, тим із ним простіше буде надалі.
Ще корисно збирати артефакти. Коли наш тест падає, він зберігає останню відповідь сервера HTML-файлик і закидає в сховище артефактів, де цей файл можна відкрити з браузера, вказавши назву тесту.
Наприклад, тест у нас впав на тому, що не може знайти на сторінці шматочок HTML:
Link
Ми заходимо на наш колектор та відкриваємо відповідну сторінку:
З цією сторінкою можна працювати так само, як з будь-якою іншою HTML-сторінкою у браузері. Можна за допомогою CSS-локатора спробувати розшукати зниклий елемент і, якщо його дійсно немає, вирішити, що він змінився, або загубився. Можливо ми знайшли баг! Якщо елемент на місці, можливо, ми помилилися в тесті – треба уважно подивитися в цей бік.
Ще спростити життя допомагає логування. Ми намагаємося логувати всі запити, які робив тест, що впав, так, щоб їх легко можна було повторити. По-перше, це дозволяє швидко руками зробити набір аналогічних дій для відтворення помилки, по-друге – виявити тести, що часто падають, якщо такі у нас є.
Крім допомоги у розборі помилок, описані вище логи допомагають нам формувати список авторизованих та неавторизованих сторінок, які ми протестували. Дивлячись на нього, легко шукати та усувати прогалини.
Останнє, але не важливо, що можу порадити – тести повинні бути настільки зручними, наскільки це можливо. Чим простіше їх запустити, тим частіше їх використовуватимуть. Чим зрозуміліший та лаконічніший звіт про падіння, тим уважніше його вивчать. Чим простіше архітектура, тим більше тестівбуде написано і тим менше часу займатиме написання нового.
Якщо вам здається, що тестами користуватись незручно – швидше за все вам не здається. З цим необхідно боротися якнайшвидше. В іншому випадку ви ризикуєте в якийсь момент почати звертати менше уваги на ці тести, а це вже може призвести до помилки на продакшн.
На словах думка здається очевидною, згоден. Але насправді всім нам є куди прагнути. Тож спрощуйте та оптимізуйте свої твори та живіть без багів. :)
Підсумки
На даний момент у нас відкриваю Тімсіті ого, вже 605 тестів. Усі тести, якщо їх запускати не паралельно, проходять трохи менше ніж за чотири хвилини.За цей час ми переконуємось, що:
- наш проект відкривається всіма мовами (яких у нас понад 40 на продакшені);
- для основних країн відображаються коректні форми оплати з відповідним набором способів оплати;
- коректно працюють основні запити до API;
- коректно працює лендинг для редиректів (у тому числі і на мобільний сайт за відповідного користувача-агента);
- все внутрішні проективідображаються правильно.
