Приклади smoke test. Пов'язані зі змінами види тестування

Два роки тому 7 тис. очок одиночного рейтингу вважалися найвищим досягненням для гравців на особистому фронті, рік тому ця планка піднялася до 8 тис., а зараз уже всі звертають увагу лише на 9 K MMR. У наші дні багато хто відкрито говорить, що поріг виходу на професійну сцену для новачків знаходиться на рівні 7K і вище. Але це ніяк не заважає кіберспортсменам, що відбулися, грати матчмейкінг на своє задоволення, не переживаючи з приводу цифр. «Чемпіонат» склав список із 10 популярних гравців, чий MMR знаходиться нижче за позначку шість з половиною тисяч очок. Більшість із них абсолютно не соромляться свого рейтингу та не приховують інформацію про нього у своїх профілях.

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

Розмір має значення. Професійні дотери про рейтинг MMR

Йоакім «Akke» Акторналл, 6,4 K MMR

Легендарний шведський саппорт, що прославилася на весь світ у складі чемпіонів The International 2013 – The Alliance. З публікацій Йоакіма в соціальних мережахстає зрозуміло, що, на відміну від молодих дотерів, що сягають рейтингу в спробі забратися на вершину списку світових лідерів, він частіше проводить час із сім'єю, гуляє в парку, ходить у кіно. Його 6,4 К MMR - цілком прийнятний рейтинг, щоб щодня підтримувати спритність у паблику з найкращими гравцями матчмейкінгу.

Кай H4nni Ханбукерс, 6,3 До MMR

28-річний німецький кіберспортсмен свої найкращі рокипровів під прапорами команди Fnatic разом з N0tail та Fly та вважався одним із найсильніших гравців центральної лінії. Його коронного Invoker боялися та поважали абсолютно усі гранди світової сцени. У травні 2015-го він пішов до інактиву, але на початку цього року повернувся на професійну сцену і зараз виступає у складі Ninjas in Pyjamas. Невисокий одиночний рейтинг змусив його поступитися центральною лінією свого молодого майстровитого співвітчизника Макса «Qojqva» Брохера, а сам Кай тепер грає на позиції сапорта.

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

Адам «343» Хуссейн, 6,3 MMR

Поодинокий рейтинг 6,3 До MMR абсолютно не заважає малазійському сапорту бути одним із найбільш затребуваних не лише у своєму регіоні, а й за його межами. На попередньому The International разом із командою Fnatic він зайняв четверте місце і заробив близько $300 тис. Взимку він пробував свої сили в європейському складі B)ears, а нещодавно заміняв Ніко «eyyou» Барселона у складі Mineski. З якою командою він пробиватиметься в Сіетл цього разу – одна із загадок трансферного вікна.

Джонатан "Loda" Берг, 6,1 До MMR

Іменитий капітан шведської The Alliance, який виступає на позиції Керрі, має у своєму активі 6,1 К MMR. Невисокий рейтинг та одна з ключових ролей у грі обертаються для Джонатана тим, що саме на нього списують останні невдачі шведського колективу. Мовляв, Берг постарів і не може похвалитися таким же великим рейтингомяк його опоненти за позицією. До речі, Loda – єдиний представник цього списку, хто грає не на позиції сапорту.

Коли дружба понад усе. Історія дуету "Lokke"

Історія одного з «олдскульних» дуетів на сучасній «Дота»-сцені, який на Заході охрестили Lokke.

Закарі "Zfreek" Фрідман, 6К MMR

Самонавідні стріли за Mirana, фантастичні «блекхоли» за Enigma, викрадені ультимети за Rubick - навряд чи зараз хтось повірить, що це справа рук гравця з 6 К MMR. Саме стільки має у своєму активі один з братів Фрідман, які стоять біля керма американської команди compLexity. У Закарі дуже креативне мислення, тому там де він завжди видовище, незважаючи на жодні цифри.

Олексій «Solo» Березін, 5,9 MMR

Свого часу Solo займав перші позиції у світовому списку лідерів по одиночному рейтингу, а також був одним із перших, кому підкорилася позначка 7 тис. очок. Пересівши на позицію гравця підтримки, Олексій став повністю концентруватися на обов'язках капітана, приділяючи менше часу матчмейкінгу. Зараз у Березіна близько 5,9 К, що абсолютно не заважає Virtus.pro досягати великих висот на міжнародній арені.

Олексій Solo Березін був одним з перших гравців, кому підкорилася позначка в 7 тис. очок одиночного рейтингу. Зараз у його активі близько 5,9 К MMR, що не заважає Virtus.pro досягати великих висот на міжнародній арені.

"Бабки не проблема". Історія народного капітана Virtus.рro

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

Браян «FLUFFNSTUFF» Лі, 5,9 MMR

Один із найдосвідченіших американських саппортів має у своєму активі 5,9 К очок одиночного рейтингу. Хоч Брайан і не може в Останнім часомпохвалитися великими успіхамина професійній сцені, свій безцінний досвід він спрямовує на розвиток доти в регіоні шляхом запису навчальних роликів для гравців-початківців. Він не соромиться застосовувати на сцені змагання деякі ідеї, взяті з матчмейкінгу. Так, саме завдяки йому світ дізнався про роумить Chaos Knight та інші неординарні стратегії.

Гордан "g0g1" Прошич, 5.8К MMR

Команда Elements Pro Gaming радує своїми результатами і потихеньку пробивається на світову арену, у тому числі беручи участь у деяких LAN-турнірах. Керує складом сербський ветеран гри g0g1, відомий своїми виступами ще з часів першої доти.

Еміліано «c4t» Іто, 5,5 MMR

Яке ж було здивування глядачів, коли Team Secret програла бразильцям із SG eSports у рамках The Kiev Major. Найбільше претензій було до драфту найтитулованішого гравця у світі Клементу «Puppey» Іванова, який він програв капітану бразильців c4t, чий одиночний рейтинг, як виявилося, становить лише 5,5 К MMR! Простеживши за останніми іграмиЕміліано, можна побачити, що він усією душею любить доту і, незважаючи на свій зоряний статус, часто грає в компанії з друзями, чий рейтинг нижчий ще на кілька тисяч. Це не заважає йому створювати проблеми для грандів світової сцени в особі таких команд, як Team Secret та Evil Geniuses.

Найбільше претензій було до драфту найтитулованішого гравця у світі Клементу «Puppey» Іванова, який він програв капітану бразильців c4t, чий одиночний рейтинг, як виявилося, становить лише 5,5 К MMR!

Вонг "Nutz" Джен Єн, 5.5К MMR

Замикає наш список саппорт сінгапурської команди Team Faceless, який має у своєму запасі 5,5 тис. очок одиночного рейтингу. Чому іменитий капітан складу Деріл «iceiceice» Кох зробив ставку при формуванні складу саме на цього гравця, який не володіє настільки великим досвідом виступів на міжнародній арені, незрозуміло, але поки що Вонг справляється зі своїми обов'язками непогано.

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

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

Приклади

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

Історія

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

Повторне народження терміна відбулося в радіоелектроніці. Перше включення нового радіоелектронного пристрою, що прийшов з виробництва, відбувається дуже короткий час(менше секунди). Потім інженер руками обмацує всі мікросхеми щодо перегріву. Мікросхема, що сильно нагрілася за цю секунду, може свідчити про грубу помилку в схемі. Якщо перше включення не виявило перегріву, то пристрій знову вмикається на більший час. Перевірка повторюється. І так далі кілька разів. Вираз «smoke-test» використовується інженерами в жартівливому сенсі, оскільки появи диму, а значить і псування частин пристрою, намагаються уникнути.

Автоматизація

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

Напишіть відгук про статтю "Smoke test"

Посилання

• на Jargon File (англ.)
• msdn.microsoft.com/ru-ua/library/ms182613(VS.90).aspx - Правила з коротким тестамвід Microsoft.

Уривок, що характеризує Smoke test

Для князя Андрія минуло сім днів з того часу, як він прийшов до тями на перев'язувальному пункті Бородинського поля. Весь цей час він перебував майже в постійному непритомності. Гаряче стан і запалення кишок, які були пошкоджені, на думку лікаря, який їхав з пораненим, повинні були забрати його. Але на сьомий день він із задоволенням з'їв скибу хліба з чаєм, і лікар помітив, що загальний жар зменшився. Князь Андрій ранком прийшов до тями. Першу ніч після виїзду з Москви було досить тепло, і князя Андрія залишили для ночівлі в колясці; але в Митищах поранений сам зажадав, щоб його винесли і щоб йому дали чаю. Біль, завданий йому перенесенням у хату, змусив князя Андрія голосно стогнати і знепритомніти. Коли його поклали на похідному ліжку, він довго лежав з закритими очимаБез руху. Потім він відкрив їх і тихо прошепотів: Що ж чаю? Пам'ятливість ця до дрібних подробиць життя вразила лікаря. Він помацав пульс і, на подив і невдоволення своєму, помітив, що пульс був кращим. До невдоволення свого це помітив лікар тому, що він з досвіду свого був переконаний, що жити князь Андрій не може і що якщо він не помре тепер, то він тільки з великими стражданнями помре кілька днів після. З князем Андрієм везли майора, що приєднався до них у Москві, його полку Тимохіна з червоним носиком, пораненого в ногу в тій же Бородінській битві. При них їхав лікар, камердинер князя, його кучер і два денники.

Привіт, Хабре! Якось на нашому внутрішньому семінарі мій керівник – голова відділу тестування – розпочав свою промову зі слів «тестування не потрібне». У залі всі притихли, дехто навіть намагався впасти зі стільців. Він продовжив свою думку: без тестування цілком можливо створити складний і дорогий проект. І, швидше за все, він працюватиме. Але уявіть, наскільки впевненіше ви почуватиметеся, знаючи, що продукт працює як треба.

У Badoo релізи відбуваються досить часто. Наприклад, серверна частина нарівні з desktop web релізується двічі на день. Так що ми не з чуток знаємо, що складне та повільне тестування – камінь спотикання розробки. Швидке тестування – це щастя. Отже, сьогодні я розповім про те, як у компанії Badoo влаштовано smoke-тестування.

Що таке smoke-тестування

В оригінальному застосуванні smoke-тестування призначене для перевірки найпростіших і очевидних кейсів, без якої будь-який інший вид тестування буде невиправдано зайвим.

Давайте розглянемо найпростіший приклад. Передпродакшн нашого додатка знаходиться за адресою bryak.com (будь-які збіги з реальними сайтами випадкові). Ми підготували та залили туди новий реліз для тестування. Що варто перевірити насамперед? Я б почав з перевірки того, що програма все ще відкривається. Якщо web-сервер нам відповідає «200», то все добре і можна приступати до перевірки функціоналу.

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

Наш перший smoke-тест

По суті тести просто роблять потрібні нам запити на сервер і перевіряють відповіді. Все пов'язане з методом 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. З тим самим успіхом ми можемо перевірити будь-яку кількість елементів на сторінці, тривалість тесту суттєво не зміниться.

Плюси таких тестів:

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

Авторизація

Найпростіший варіант - авторизаційна 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: ". $response);
Після того, як cookies отримані, ми можемо сміливо додавати їх до будь-якого запиту, щоб зробити його авторизованим.

Розбір тестів, що падають

Насамперед я хотів би порадити максимально атомізувати тести. Не варто в одному тесті перевіряти 50 різних кейсів. Чим тест простіше, тим із ним простіше буде надалі.

Ще корисно збирати артефакти. Коли наш тест падає, він зберігає останню відповідь сервера HTML-файлик і закидає в сховище артефактів, де цей файл можна відкрити з браузера, вказавши назву тесту.

Наприклад, тест у нас впав на тому, що не може знайти на сторінці шматочок HTML:

Link
Ми заходимо на наш колектор та відкриваємо відповідну сторінку:

З цією сторінкою можна працювати так само, як з будь-якою іншою HTML-сторінкою у браузері. Можна за допомогою CSS-локатора спробувати розшукати зниклий елемент і, якщо його дійсно немає, вирішити, що він змінився, або загубився. Можливо ми знайшли баг! Якщо елемент на місці, можливо, ми помилилися в тесті – треба уважно подивитися в цей бік.

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

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

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

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

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

Підсумки

За цей час ми переконуємось, що:

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

• Smoke test на Jargon File (англ.)

Wikimedia Foundation. 2010 .

Дивитись що таке "Smoke test" в інших словниках:

smoke test- noun Оцінка методу випробування для легенів в drain pipes or chimneys, щоб встановити штучний кукурудза, триматися за допомогою кукурудзи Bomb Main Entry: smoke … Useful english dictionary

smoke test- Test made to determine completeness of combustion … Dictionary of automotive terms

smoke test- 1. noun a) A test for leaks involving blowing smoke в tube or pipe. b) Попередній тест на нову конструктивну частину електричного обладнання, що містить лише застосування електричної напруги, що робить не те, що егрегиусный wiring ... ... Вікно

Smoke testing- є терміном, який використовувався в plumbing, woodwind repair, electronics, computer software development, and theцентрування промисловості. It refers to the first test made after repairs or first assembly to provide some assurance that the system under test will… … Wikipedia

Smoke testing- bzw. Rauchtest is ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten… … Deutsch Wikipedia

Smoke- is collection of airborne solid and liquid particulates and gases [

Test suite- У розробці програмного забезпечення, в обчислювальних приладах, як і раніше відомо, як validation suite , є колекція тестових випадків, які будуть впроваджені для того, щоб бути використані в обліковий запис програмного забезпечення для того, щоб виявити певну версію behaviours. A test suite often… … Wikipedia

Smoke bomb- A smoke bomb is a firework designed to produce smoke upon ignition. While there are Smoke generating devices, що є схиблені від аеродпланів, терм губи бомби, використовувані для трьох типів пристроїв: # Smoke ball is hollow, cherry ... ... Wikipedia

Переклад розбавлений роздумами та доповненнями автора зі свого досвіду

Про що це все

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

Для новачків у тестуванні (і навіть досвідчених тестувальників) поділ цих понять може бути скрутним. І справді, як відрізнити де починається саніті-тестування та закінчується smoke? Наскільки сильно нам треба обмежити перевірку частини функціональності системи чи її компонентів, щоб назвати це «димовим» тестуванням? Чи є введення логіна/паролю в форму користувача входу на сайт димовим тестом, або сам факт появи на сторінці сайту вже є пройденим тестом?

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

Лікнеп

• Димові тести: виконуються кожного разу, коли ми отримуємо новий білд (версію), проекту (системи) на тестування, вважаючи її відносно нестабільною. Нам потрібно переконатися, що критично важливі функції AUT (Application Under Test) працюють відповідно до очікувань. Ідея цього виду тестування полягає в тому, щоб виявити серйозні проблемиякомога раніше, і відхилити цей білд (повернути на доопрацювання) на ранньому етапі тестування, щоб не заглиблюватися в довгі та складні тести, не витрачаючи тим самим час на заздалегідь браковане програмне забезпечення.
• Санітарне тестування: використовується щоразу, коли ми отримуємо відносно стабільний білд, щоб визначити працездатність в деталях. Іншими словами, тут відбувається валідація того, що важливі частини функціональності системи працюють згідно з вимогами на низькому рівні.

• Ре-тест: проводиться у випадку, якщо фіча/функціональність вже мала дефекти, і ці дефекти були нещодавно виправлені.
• Регресійні тести: власне те, що займає левову часткучасу та навіщо існує автоматизація тестування. Проводиться регресійне тестування AUT тоді, коли потрібно переконатися, що нові (додані) функції програми / виправлені дефекти не вплинули на поточну, вже існуючу функціональність, що працювала (і протестовану) раніше.

Ну, а по суті?

Приклад: у нас є веб-сервіс з інтерфейсом користувача і RESTful API. Будучи тестувальниками, ми знаємо:

• Що має 10 точок входу, для простоти, в нашому випадку розміщених на одному IP
• Ми знаємо, всі вони приймають GET-запит на вхід, повертаючи будь-які дані у форматі json.

• Виконавши один простий GET-запит до однієї з цих точок входу і отримавши відповідь у форматі json, ми вже переконуємося, що димне тестування пройдено.
  Якщо одна з цих точок входу так само повертає дані з БД, тоді як перша - ні, потрібно додатково виконати ще один запит, щоб переконатися, що додаток
  чітко обробляє запити до бази. І на цьому «димний» тест закінчено.

  Тобто ми виконали запит - від сервісу надійшла відповідь, і він не «задимився», тобто не повернув помилку 4хх або 5хх, і щось невиразне замість json. На цьому можна сказати, що «димний» тест пройдено. Для перевірки того, що працює так само і UI, досить просто один раз відкрити сторінку в браузері.

• Санітарне тестування в даному випадку складатиметься з виконання запиту до всіх 10 точок входу в api, звіркою отриманого json з очікуваним, а також наявністю необхідних даних у ньому.
• Регресійні тести будуть складатися з smoke + sanity + UI, що виконуються разом в одній купі. Мета: перевірити, що додавання 11-ої точки входу не поламало, наприклад, відновлення пароля.
• Ре-тест у цьому прикладі це точкова перевірка що, наприклад, точка входу в api, що зламалася, в наступному білді відпрацьовує як замислювалося.

Підведемо підсумок

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

Дякую за наведення