Різниця між тестуванням диму та розуму - це найбільш неправильно зрозуміла тема в тестуванні програмного забезпечення. Існує величезна кількість літератури на цю тему, але більшість з них викликає заплутаність. Наступна стаття робить спробу усунути плутанину.
Основні відмінності між тестуванням диму та тестуванням розумності можна дізнатись за допомогою наступної схеми -
Тестування диму проти тесту на розум
Щоб оцінити наведену вище діаграму, давайте спочатку зрозуміємо -
Що таке збірка програмного забезпечення?
Якщо ви розробляєте просту комп'ютерну програму, яка складається лише з одного файлу вихідного коду, вам просто потрібно скомпілювати і зв'язати цей один файл, щоб створити виконуваний файл. Цей процес дуже простий.
Зазвичай це не так. Типовий проект програмного забезпечення складається з сотень або навіть тисяч файлів вихідного коду. Створення виконуваної програми з цих вихідних файлів є складним і трудомістким завданням.
Вам потрібно використовувати програмне забезпечення "build" для створення виконуваної програми, і процес називається "Software Build"
Тестування диму
Тестування диму - це техніка тестування програмного забезпечення, що виконується після побудови програмного забезпечення, щоб переконатися, що критичні функціональні можливості програмного забезпечення працюють нормально. Він виконується перед виконанням будь-яких детальних функціональних або регресійних тестів. Основною метою тестування диму є відмова від програмного забезпечення з дефектами, щоб команда контролю якості не витрачала час на тестування зламаного програмного забезпечення.
Під час тестування диму тестові кейси вирішили охопити найважливішу функціональність або компонент системи. Завдання полягає не в тому, щоб провести вичерпне тестування, а в тому, щоб перевірити, чи відповідають критичні функціональні можливості системи.
Наприклад, типовим тестом на дим може бути - Переконайтесь, що програма успішно запускається, Переконайтесь, що графічний інтерфейс реагує ... тощо.
КЛЮЧОВА РІЗНИЦЯ
- Тестування на дим має на меті перевірити “стабільність”, тоді як Тестування на розумність має на меті перевірити “раціональність”.
- Тестування диму проводять як розробники, так і тестувальники, тоді як Тестування на розумність проводять тестери.
- Тестування диму перевіряє критичні функціональні можливості системи, тоді як Тестування на розум перевіряє нові функції, такі як виправлення помилок.
- Тестування на дим є підмножиною тестів прийнятності, тоді як тестування на обґрунтованість є підгрупою тестів на регресію.
- Тестування на дим задокументоване чи сценарій, тоді як тестування на розум ні.
- Тестування на дим перевіряє всю систему від кінця до кінця, тоді як перевірка осудності перевіряє лише певний компонент.
Що таке перевірка розумності?
Тестування на обґрунтованість - це різновид Тестування програмного забезпечення, що проводиться після отримання збірки програмного забезпечення, з незначними змінами в коді чи функціональних можливостях, щоб переконатися, що помилки виправлені, і через ці зміни не виникає жодних подальших проблем. Мета полягає в тому, щоб визначити, що запропонована функціональність працює приблизно так, як очікувалося. Якщо перевірка розумності не вдається, збірка відхиляється, щоб заощадити час і витрати, пов'язані з більш суворим тестуванням.
Метою є "не" ретельно перевірити нову функціональність, а визначити, що розробник застосував певну раціональність (розумність) під час виробництва програмного забезпечення. Наприклад, якщо ваш науковий калькулятор дає результат 2 + 2 = 5! Тоді немає сенсу тестувати такі розширені функціональні можливості, як sin 30 + cos 50.
Тестування диму проти перевірки розумності - ключові відмінності
Нижче наведена різниця між тестуванням на осудність і дим:
| Тестування диму | Перевірка розумності |
|---|---|
| Тестування диму проводиться для того, щоб переконатися, що найважливіші функції програми працюють нормально | Перевірка розумності проводиться для перевірки виправлення нових функціональних можливостей / помилок |
| Мета цього тестування - перевірити "стабільність" системи, щоб продовжити більш суворе тестування | Мета тестування - перевірити "раціональність" системи, щоб продовжити більш суворе тестування |
| Це тестування проводиться розробниками або тестувальниками | Тестування на обґрунтованість при тестуванні програмного забезпечення зазвичай проводять тестувальники |
| Тестування на дим зазвичай оформляється документально або за сценарієм | Тестування на обґрунтованість, як правило, не задокументоване та не є сценарієм |
| Тестування на дим є підмножиною тестів на прийняття | Тестування на розумність є підмножиною тестування на регресію |
| Тестування на дим вправляє всю систему від кінця до кінця | Перевірка розумності здійснює лише певний компонент всієї системи |
| Тестування на дим - це як загальна перевірка стану здоров’я | Перевірка розумності - це як спеціалізована перевірка стану здоров’я |
Бали, на які слід звернути увагу.
- Тестування на розум і дим - це способи уникнути марної витрати часу та зусиль, швидко визначивши, чи є програма занадто хибною, щоб заслужити будь-яке суворе тестування.
- Випробування диму також називають випробувальними тестами.
- Тестування диму, проведене на певній збірці, також відоме як тест перевірки збірки .
- Однією з найкращих галузевих практик є проведення щоденного тестування збірки та диму в програмних проектах.
- І тести на задимленість і осудність можна проводити вручну або за допомогою автоматичного інструменту . Коли використовуються автоматизовані інструменти, тести часто ініціюються тим самим процесом, який генерує саму збірку.
- Відповідно до потреб тестування, можливо, вам доведеться виконати як перевірку розумності, так і дим у збірці програмного забезпечення. У таких випадках спочатку виконують тести на дим, а потім продовжують тестування на розум. У промисловості тестові кейси для перевірки осудності зазвичай поєднують з тестами для тестування диму, щоб пришвидшити виконання тестів. Отже, загальноприйнятим є те, що терміни часто плутають і використовують як взаємозамінні
Клацніть тут, якщо відео недоступне
Докладніше про тестування диму в програмній інженерії
