Що таке одиничні випробування, інтеграційні тести, димові тести та регресійні тести?

Що таке одиничні випробування, інтеграційні тести, димові тести та регресійні тести? У чому полягають відмінності між ними та які інструменти я можу використовувати для кожного з них?

Наприклад, я використовую JUnit та NUnit для тестування одиниць та інтеграції . Чи є інструменти для останніх двох, тестування димом чи регресійне тестування ?

• Тест одиниці : Вкажіть і випробуйте одну точку договору одинарного методу класу. Це повинно мати дуже вузьку і чітко визначену сферу застосування. Складні залежності та взаємодії із зовнішнім світом заглушені або знущаються .

• Інтеграційний тест : перевірка правильності взаємодії декількох підсистем. Там є весь спектр - від тестування інтеграції двох класів, до тестування інтеграції з виробничим середовищем.

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

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

• Регресійний тест : тест, який було написано, коли виправлено помилку. Це гарантує, що ця конкретна помилка не повториться. Повна назва - "нерегресійний тест". Це також може бути тест, зроблений до зміни програми, щоб переконатися, що додаток забезпечує той самий результат.

До цього я додам:

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

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

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

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

У кожного будуть дещо різні визначення, і часто є сірі ділянки. Однак:

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

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

Прикладами можуть бути:

• Є дані , які повинні завжди бути доступні в розробці / запальним з'явився живий ?
• Не вдалося запустити фоновий процес?
• Чи може користувач увійти?

Відповідь одного з найкращих веб-сайтів щодо методів тестування програмного забезпечення:

Види тестування програмного забезпечення - повний список натисніть тут

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

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

Інтеграційний тест: перевірка функціонування взаємодії певних компонентів. Інтеграційні випробування можна проводити на рівні одиниць або на рівні системи. Ці тести можуть бути ручними або автоматизованими.

Регресійний тест: перевірка того, що нові дефекти не внесені в існуючий код. Ці тести можуть бути ручними або автоматизованими.

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

Набір інструментів багато в чому залежатиме від бази даних коду, але існує багато інструментів з відкритим кодом для тестування одиниць (JUnit). QTP від ​​HP (Mercury) або тест на шовк Borland - це інструменти для автоматизованої інтеграції та тестування регресії.

Тест блоку : тестування окремого модуля або незалежного компонента в додатку, як відомо, є одиничним тестуванням. Тестування пристрою буде виконано розробником.

Тест на інтеграцію : поєднання всіх модулів та тестування програми для перевірки зв'язку та потоку даних між модулями працюють належним чином чи ні. Це тестування також виконували розробники.

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

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

ТЕСТУВАННЯ РЕГРЕСІЇ-

"Тест регресії повторно проводить попередні тести щодо зміненого програмного забезпечення, щоб переконатися, що зміни, внесені в поточне програмне забезпечення, не впливають на функціональність існуючого програмного забезпечення."

Я просто хотів додати і дати ще трохи контексту про те, чому ми маємо ці рівні тестування, що вони насправді означають на прикладах

Майк Кон у своїй книзі «Успіх з Agile» придумав «Піраміду тестування» як спосіб підійти до автоматизованих тестів у проектах. Існують різні інтерпретації цієї моделі. Модель пояснює, який тип автоматизованих тестів потрібно створити, наскільки швидко вони можуть надати відгук про тестовану програму та хто пише ці тести. В основному є 3 рівні автоматизованого тестування, необхідні для будь-якого проекту, і вони наступні.

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

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

Історично розробник пише ці тести, оскільки вони, як правило, написані тією ж мовою програмування, що і програмне забезпечення. Для цього використовуються одиничні рамки тестування, такі як JUnit і NUnit (для Java), MSTest (для C # і .NET) та Jasmine / Mocha (для JavaScript).

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

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

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

Історично розробник або технічний контроль якості писали б ці тести, використовуючи різні інструменти, такі як Postman, SoapUI, JMeter та інші інструменти, такі як Testim.

Вони запускаються набагато швидше, ніж тести користувальницького інтерфейсу, оскільки вони все ще працюють під кришкою, але це може зайняти трохи більше часу, ніж тести для одиниць, оскільки це повинно перевірити зв'язок між різними незалежними компонентами системи та забезпечити безперебійну інтеграцію. Це повинно становити більше 30% автоматизованих тестів.

Тести користувальницького інтерфейсу - Нарешті, у нас є тести, які підтверджують користувальницький інтерфейс програми. Ці тести, як правило, пишуться для тестування потоків в кінці через додаток.

Наприклад - у програмі для калькулятора може бути потоковий перехід до кінця, відкриваючи браузер-> Введення URL-адреси програми калькулятора -> Вхід з ім'ям користувача / паролем -> Відкриття програми калькулятора -> Виконання деяких операцій на калькуляторі -> перевірка цих результатів через інтерфейс користувача -> вихід із програми. Це може бути потоком від кінця до кінця, який був би хорошим кандидатом для автоматизації інтерфейсу користувача.

Історично, технічні QA або ручні тестери пишуть користувальницькі тести. Вони використовують рамки з відкритим кодом, такі як платформи тестування Selenium або UI, такі як Testim, для авторів, виконання та підтримки тестів. Ці тести дають більше візуального зворотного зв’язку, оскільки ви можете бачити, як працюють тести, різницю між очікуваними та фактичними результатами через скріншоти, журнали, звіти про тести.

Найбільшим обмеженням тестів на інтерфейс є те, що вони відносно повільні порівняно з тестами рівня Unit та API. Отже, він повинен становити лише 10-20% загальних автоматизованих тестів.

Наступні два типи тестів можуть залежати від вашого проекту, але ідея полягає в тому,

Димові тести

Це може бути поєднання вищевказаних 3 рівнів тестування. Ідея полягає у тому, щоб запустити його під час кожного перевірки коду та переконатися, що критичні функції системи все ще працюють, як очікувалося; після того як нові зміни коду будуть об'єднані. Зазвичай їм потрібно запустити 5 - 10 хвилин, щоб отримати швидший зворотній зв'язок про збої

Регресійні тести

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

Блок тестування спрямований на найменшу частину можливої ​​реалізації. На Java це означає, що ви протестуєте один клас. Якщо клас залежить від інших класів, вони підроблені.

Коли ваш тест називає більше одного класу, це інтеграційний тест .

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

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

• Тестування інтеграції: Тестування інтеграції - це інтеграція іншого елемента
• Тестування диму: тестування димом також відоме як тестування версії версії. Тестування димом - це початковий процес тестування, який перевіряється, чи програмне забезпечення, яке випробовується, готове / стабільне для подальшого тестування.
• Регресійне тестування: Регресійне тестування - це повторне тестування. Будь нове програмне забезпечення виконане в іншому модулі чи ні.
• Тестування блоку: це тестування білого поля. ТількиУ ньому беруть участь розробники

Тест блоку: Перевірка того, що конкретний компонент (тобто клас) створив або змінив функції, як було розроблено. Цей тест може бути ручним або автоматизованим, але не переміщується за межі компонента.

Інтеграційний тест: перевірка функціонування взаємодії певних компонентів. Інтеграційні випробування можна проводити на рівні одиниць або на рівні системи. Ці тести можуть бути ручними або автоматизованими.

Регресійний тест: перевірка того, що нові дефекти не внесені в існуючий код. Ці тести можуть бути ручними або автоматизованими.

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

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

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

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

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

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

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

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

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

Тести продуктивності за своєю суттю є досить дорогими для впровадження та запуску, але вони можуть допомогти вам зрозуміти, якщо нові зміни погіршать систему.

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

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

Джерело: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

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

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

Тестування диму: тестер виконується для перевірки системи перевірки на високому рівні та намагається з'ясувати показ помилки стоппер перед тим, як зміни чи код почне діяти.

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

Тестування одиниць

Тестування одиниць, як правило, проводиться стороною розробників, тоді як тестери частково розвиваються в цьому типі тестування, коли тестування проводиться по одній одиниці. У тестових випадках Java JUnit також можна перевірити, чи написаний код ідеально розроблений чи ні.

Інтеграційне тестування:

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

Тестування диму

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

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

Регресійне тестування

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

Випробування на дим та обґрунтованість виконуються після складання програмного забезпечення, щоб визначити, чи варто починати тестування. Розсудливість може бути, а може і не бути виконана після тестування димом. Вони можуть бути виконані окремо або одночасно - ощадливість бути негайно після диму.

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

Тестування диму зазвичай займає не більше 5-30 хвилин для виконання. Він більш загальний: він перевіряє невелику кількість основних функцій всієї системи, щоб переконатися, що стабільність програмного забезпечення достатньо хороша для подальшого тестування і що немає проблем, блокуючи виконання запланованих тестових випадків.

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

Вже є кілька хороших відповідей, але я хотів би їх детальніше уточнити:

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

Тож чітке тестування - це єдине тестування білого поля.

• Блок тестування конкретних фрагментів коду. Зазвичай методи.
• Інтеграційне тестування перевіряє, чи може ваша нова функціональна частина програмного забезпечення інтегруватися з усім іншим.
• Регресійне тестування. Це тестування, щоб переконатися, що ви нічого не зламали. Все, що раніше працювало, все одно має працювати.
• Тестування диму робиться як швидкий тест, щоб переконатися, що все виглядає нормально, перш ніж ви будете брати участь у більш енергійному тестуванні.

Випробування на дим уже пояснено тут і є простим. Регресійні тести підпадають під інтеграційні тести.

Автоматизовані тести можна розділити лише на два.

Тести для модулів та інтеграційні тести (це все, що має значення)

Я б назвав використовувати словосполучення "довгий тест" (LT) для всіх тестів, таких як інтеграційні тести, функціональні тести, регресійні тести, тести користувальницького інтерфейсу тощо. І одиничні тести як "короткий тест".

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

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

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

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