Що таке тестування диму?
Томас Гамільтон
⚡ Розумний підсумок
Тестування Smoke визначає, чи є нова збірка достатньо стабільною для тестування. На цій сторінці пояснюється, коли її запускати, хто її запускає, як працює цикл і як автоматизовані пакети обробляють сучасні конвеєри доставки.
Що таке тестування диму?
Тестування диму це процес тестування програмного забезпечення, який визначає, чи є розгорнута збірка програмного забезпечення стабільною чи ні. Димове тестування є підтвердженням для команди QA продовжити подальше тестування програмного забезпечення. Він складається з мінімального набору тестів, які виконуються на кожній збірці для перевірки функцій програмного забезпечення. Димове тестування також відоме як «Тестування верифікації збірки» або «Тестування достовірності».
Простіше кажучи, димове тестування означає перевірку роботи важливих функцій та відсутності недоліків у збірці, що тестується. Це міні- та швидке регресійне тестування основної функціональності. Це допомагає визначити, чи є в збірці недоліки, щоб будь-яке подальше тестування не стало марною тратою часу та ресурсів.
Порівняти Дим проти здорового глузду
Чому ми проводимо тестування на дим?
Димове тестування відіграє важливу роль у розробці програмного забезпечення, оскільки воно забезпечує коректність системи на початкових етапах. Завдяки цьому ми можемо заощадити зусилля на тестування. Тільки після завершення димового тестування ми починаємо функціональне тестування.
- Усі головні недоліки збірки будуть ідентифіковані шляхом проведення димового тестування.
- За допомогою димових випробувань більшість дефектів виявляються на початкових стадіях розробка програмного забезпечення.
- За допомогою димового тестування ми спрощуємо виявлення та виправлення основних дефектів.
- За допомогою димового тестування команда контролю якості може виявити дефекти у функціональності програми, які могли виявитися через новий код.
- Тестування димом виявляє основні дефекти серйозності.
Приклад 1: Вікно реєстрації: можливість переходу до наступного вікна з дійсним іменем користувача та паролем після натискання кнопки «Надіслати».
Приклад 2: Користувач не може вийти з веб-сторінки.
Коли ми проводимо тестування на дим?
Ці переваги матеріалізуються лише тоді, коли перевірку запускають у потрібний момент. Димове тестування проводиться щоразу, коли нові функції програмного забезпечення розробляються та інтегруються з існуючою збіркою, яка розгортається в середовищі контролю якості/проміжного тестування. Воно гарантує, що всі критичні функції працюють правильно чи ні. На діаграмі нижче показано, як збірка потрапляє до середовища контролю якості до початку димового тестування.
У цьому методі тестування команда розробників розгортає збірку в режимі контролю якості. Підмножина тестових випадків береться та запускається тестувальниками для перевірки критичних функцій збірки. Ці серії тестових випадків розроблені для виявлення помилок, що є в збірці. Якщо ці тести пройдено, команда контролю якості продовжує роботу. Функціональне тестування.
Будь-який збій вказує на необхідність повернути систему команді розробників. Щоразу, коли в збірку вносяться зміни, ми проводимо тестування на дим, щоб забезпечити стабільність.
Приклад: -Нова кнопка реєстрації додається у вікно входу, і збірка розгортається з новим кодом. Ми проводимо тестування на дим новобудови.
Димові тести кваліфікують збірку для подальшого формального тестування та призначені для демонстрації стабільності системи та відповідності вимогам. Головна мета — виявити основні проблеми на ранній стадії. Збірка включає всі файли даних, бібліотеки, модулі повторного використання, спроектовані компоненти, необхідні для реалізації однієї або кількох функцій продукту.
Що станеться, якщо ми не проведемо тестування на дим
Якщо ми не проведемо тестування на дим на ранніх стадіях, дефекти можуть виникнути на пізніших стадіях, що може дорого коштувати. Дефект виявлені на пізніших етапах можуть бути перешкодою, яка впливає на випуск результатів.
Хто проводитиме тестування на дим?
Після випуску збірки для середовища QA інженери з QA/керівник QA виконують тестування диму. Кожного разу, коли з’являється нова збірка, команда контролю якості визначає основні функції програми для проведення тестування диму. Команда контролю якості перевіряє програму, яка тестується, на наявність шоустоперів.
Як провести тестування на дим?
Випробування диму зазвичай виконується вручну, хоча існує можливість виконати те саме за допомогою автоматизації. Це може відрізнятися від організації до організації.
Ручне тестування диму
Димове тестування проводиться для того, щоб переконатися, що навігація критичними шляхами відповідає очікуванням і не перешкоджає функціональності. Вибираються високопріоритетні тестові випадки функціональності та тестуються для виявлення критичних дефектів у системі. Якщо тест проходить успішно, ми продовжуємо функціональне тестування. Якщо тест не проходить, збірка відхиляється та надсилається назад команді розробників для виправлення.
Відділ контролю якості знову починає димове тестування з новою версією збірки. Димове тестування виконується на новій збірці та буде інтегровано зі старими збірками для підтримки коректності системи. Перед початком димового тестування команда контролю якості повинна перевірити наявність правильних версій збірки.
Тестування диму за допомогою автоматизації
Тестування автоматизації використовується для Регресійне тестуванняОднак, ми також можемо використовувати набір автоматизованих тестових випадків для запуску Smoke Test. За допомогою автоматизованих тестів розробники можуть негайно перевіряти збірку, коли є нова збірка, готова до розгортання.
Замість повторного тестування вручну щоразу, коли розгортається нова збірка програмного забезпечення, записані випадки димового тестування виконуються для збірки. Він перевіряє, чи все ще належним чином працюють основні функції. Якщо тест провалиться, вони можуть виправити збірку та негайно повторно розгорнути її. Завдяки цьому ми можемо заощадити час і забезпечити якісне створення середовища контролю якості.
Використовуючи автоматизований інструмент, інженер-випробувач записує всі ручні кроки, які виконуються під час створення програмного забезпечення.
Цикл випробувань диму
Наведена нижче блок-схема показує, як виконується Smoke Testing. Після розгортання збірки в QA та успішного проходження Smoke Tests ми переходимо до функціонального тестування. Якщо Smoke Test не пройде, ми завершуємо тестування, доки проблема в збірці не буде вирішена.
Найкращі практики для розробки тестових випадків диму
Знати цикл – це одне; триматиping Набір, який робить його надійним, — це зовсім інший. Набір для копчення заслужує своє місце лише тоді, коли він залишається компактним, швидким та повторюваним.
- Спочатку намалюйте критичні шляхи: Перелічіть робочі процеси, які роблять продукт комерційно придатним для використання, такі як вхід, пошук, введення даних, оплата та вихід. Якщо один з них зламається, збірка не матиме цінності для тестувальника.
- Зберігайте кімнату неглибокою, але широкою: Торкніться кожного основного модуля один раз, замість того, щоб досліджувати його детально. Граничні значення, негативні дані та формулювання повідомлень про помилки належать до функціонального тестування, а не до цього.
- Обмежте час виконання: Більшість команд витримують пробіжку від десяти до п'ятнадцяти хвилин і обмежують набір приблизно двадцятьма-тридцятьма хвилинами. тестові справиБіг, який триває годину, перестає бути воротами та перетворюється на вузьке місце.
- Запускайте ті самі випадки на кожній збірці: Узгодженість дозволяє вам приписувати невдачу коду, а не зміненому вибору тесту.
- Видаліть ненадійні та залежні випадки: Випадок, який проходить і не проходить без будь-яких змін коду, руйнує довіру до гейту. Заглушки або фіктиві нестабільні сторонні сервіси, де фреймворк для автоматизації тестування дозволяє.
- Запишіть один однозначний вердикт: У кожному випадку потрібен один очікуваний результат, щоб збірку можна було прийняти або відхилити без обговорення.
- Версія пакету зі збіркою: Зберігайте випадки диму в тому ж репозиторії, що й код програми, щоб шлюз завжди відповідав тестованому випуску.
Revпереглядайте пакет у кожному випуску: видаляйте випадки для функцій, які більше не мають значення, та додавайте нові критично важливі робочі процеси.
Випробування димом у трубопроводах CI/CD
Набір, розроблений таким чином, достатньо дешевий для запуску на кожному коміті, чого вимагає сучасна доставка. безперервна інтеграція сервер, такий як Jenkins компілює код, розгортає його в проміжному середовищі, а потім запускає smoke suite як перший автоматизований етап. Зелений запуск переносить артефакт на функціональний та регресійний етапи, тоді як червоний запуск призводить до невдалого завершення конвеєра та повідомляє розробника, який його затвердив, протягом кількох хвилин.
Поширеними є два варіанти розміщення. Запуск перед злиттям захищає головну гілку, перевіряючи кожен запит на злиття, а запуск після розгортання підтверджує, що розгорнуте середовище доступне та налаштоване правильно. Команди, які практикують безперервне розгортання, часто додають третій, скорочений запуск до продакшену одразу після релізу.
Оскільки конвеєр виконує набір завдань багато разів на день, випадки повинні бути неінтерактивними, самоочисними та незалежними. Будь-який випадок, який очікує на рішення людини або залишає тестові дані, зупинить конвеєр.
Переваги тестування диму
Ось декілька переваг тестування на дим.
- Легко виконувати та швидко працює
- Критичні помилки та дефекти легко виявити та виправити на ранніх стадіях.
- Покращує якість системи
- Зменшує ризик
- Прогрес легше оцінити.
- Економить зусилля та час тестування
- Мінімізує ризики інтеграції
⚠ Обмеження, яке слід зазначити: Побіжний «дим» лише свідчить про те, що збірка придатна для тестування. Він поверхнево зачіпає основні функціональні можливості, тому незначні дефекти, граничні випадки та рідко використовувані функції залишаються прихованими до запуску функціонального та регресійного тестування. Ніколи не сприймайте результат «зеленого диму» як ознаку того, що збірка не має дефектів.
Тестування диму проти тестування здорового глузду проти регресійного тестування
Усі три запускаються після зміни коду, тому їх часто плутають. Вони відрізняються обсягом, глибиною та питанням, на яке відповідає кожен.
Тестування коду, яке проводиться в середовищі розробки для забезпечення коректності програми перед випуском збірки на перевірку якості, називається тестуванням бездоганності. Це процес, який перевіряє, чи відповідає розроблювана програма основним функціональним вимогам.
Тестування працездатності визначає завершення етапу розробки та приймає рішення про проходження чи не проходження програмного продукту для подальшого етапу тестування.
| ОСНОВА | ВИПРОБУВАННЯ НА ДИМ | ПЕРЕВІРКА НА ВІДПОВІДНІСТЬ | РЕГРЕСІЙНЕ ТЕСТУВАННЯ |
|---|---|---|---|
| Сфера | Широкий і неглибокий | Вузький і глибокий | Широкий і глибокий |
| Відповідь на запитання | Чи достатньо стабільна ця збірка для тестування? | Чи працює це конкретне виправлення? | Щось із того, що раніше працювало, зламалося? |
| Послідовність | По-перше, на кожній збірці | Після проходження тесту на дим | Після перевірки на осудність |
| Типова тривалість | 10 до 15 хвилин | 30 до 60 хвилин | Hours до днів |
| Підходить для автоматизації | Дуже високо | Помірний, часто ручний | Дуже високо |
На практиці вони виконуються послідовно: димне тестування для прийняття збірки, тестування на працездатність для перевірки доставлених змін та регресійне тестування, коли дозволяє графік.
Приклад тестування диму
У таблиці нижче задокументовано короткий набір димових тестів, один рядок на критичний шлях.
| T.ID | СЦЕНАРІЇ ТЕСТІВ | ОПИС | ТЕСТОВИЙ КРОК | ОЧІКУВАНИЙ РЕЗУЛЬТАТ | АКТУАЛЬНИЙ РЕЗУЛЬТАТ | СТАТУС |
|---|---|---|---|---|---|---|
| 1 | Дійсні облікові дані для входу | Перевірте функціональність входу у веб-програму, щоб переконатися, що зареєстрованому користувачеві дозволено входити за допомогою імені користувача та пароля | 1. Запустіть програму 2. Перейдіть на сторінку входу 3. Введіть дійсне ім'я користувача 4.Введіть дійсний пароль 5.Натисніть кнопку входу |
Вхід має бути успішним | як і очікувалося | Проходити |
| 2 | Додавання функцій предмета | Можливість додавання товару в кошик | 1. Виберіть список категорій 2. Додайте товар у кошик |
Товар має бути доданий у кошик | Товар не додається в кошик | Невдача |
| 3 | Функція виходу | Перевірте функцію виходу | 1. виберіть кнопку вийти | Користувач повинен мати можливість вийти. | Користувач не може вийти | Невдача |
