Тестване за здрав разум срещу тестване за дим: ключови разлики, примери и кога да се използва всяко от тях

по: Томас Хамилтън Томас Хамилтън
Hours Обновено

⚡ Кратко резюме

Тестване за здрав разум срещу тестване за дим са два основни метода за тестване на софтуер, фокусирани върху валидирането на стабилността и рационалността на системата след изграждането. И двата целят да предотвратят загубата на усилия за осигуряване на качеството чрез идентифициране на нестабилни или дефектни компилации в началото на цикъла на тестване.

  • FoundationКонцепция: Тестването с дим потвърждава цялостната стабилност на компилацията, като проверява критичните функционалности веднага след компилацията на софтуера.
  • Валидация на здрав разум: Тестването за разумност се фокусира върху проверката на рационалността след малки актуализации на кода или функционалността.
  • Изпълнителна роля: Димните тестове се извършват от разработчици или тестери; тестовете за здравословен разум обикновено се изпълняват единствено от тестери.
  • Йерархия на тестване: Тестването за дим е подмножество на тестването за приемане; тестването за здравословен разум се подрежда под регресионното тестване.
  • Обхват на покритие: Тестването за дим оценява цялото приложение; тестването за здравословност ограничава обхвата до специфични модули.
  • Стратегия за ефективност: Най-добрата практика включва извършване на димни тестове преди проверка за здравословен начин на работа.
Прочетете повече

Тестване за здрав разум срещу тестване за дим

Тестване за дим срещу тестване за здрав разум: Сравнителна таблица

Аспект Тестване на дим Тестване за вменяемост
Основна цел Проверете стабилността на изграждането Проверете функционалността на промените
Обхват Широко (цялото приложение) Тесен (специфични модули)
Дълбочина Плитко тестване Дълбоко тестване (целенасочено)
Изпълнено от Разработчици или тестери Само за тестери
Състояние на изграждане Първоначални/нестабилни компилации Сравнително стабилни компилации
документация Сценарий и документиране Обикновено без сценарий
Тестващо подмножество Тест за приемане Тестване на регресия
Автоматизация Силно препоръчително Може да бъде ръчно или автоматизирано
Тест за дим срещу тест за здравина
Тест за дим срещу тест за здравина

Какво е компилация на софтуер?

Ако сте разработениping проста компютърна програма, която се състои само от един файл с изходен код, просто трябва да компилирате и свържете този файл, за да създадете изпълним файл. Този процес е лесен. Обикновено това не е така. Типичен софтуерен проект се състои от стотици или дори хиляди файлове с изходен код. Създаването на изпълнима програма от тези изходни файлове е сложна и отнемаща време задача. Трябва да използвате софтуер за „изграждане“, за да създадете изпълнима програма, а процесът се нарича „Изграждане на софтуер“.

Какво е тестване на дим?

Димното тестване е техника за тестване на софтуер, извършвана след компилацията на софтуера, за да се провери дали критичните функционалности на софтуера работят правилно. То се изпълнява преди да се изпълнят подробни функционални или регресионни тестове. Основната цел на димното тестване е да се отхвърли софтуерно приложение с дефекти, така че екипът по контрол на качеството да не губи време за тестване на повредено софтуерно приложение.

При Smoke Testing избраните тестови случаи обхващат най-критичната функционалност или компонент на системата. Целта не е изчерпателно тестване, а гарантиране, че ключовите функционалности на софтуерното приложение работят правилно. Например, типичен Smoke Test би проверил дали приложението се стартира успешно, дали графичният потребителски интерфейс е отзивчив и т.н.

Какво представлява тестването за здравия разум?

Тестването за разумност е вид тестване на софтуер, извършвано след получаване на софтуерна компилация с малки промени в кода или функционалността, за да се установи, че грешките са отстранени и че не са възникнали допълнителни проблеми поради тези промени. Целта е да се определи дали предложената функционалност работи приблизително както се очаква. Ако тестът за разумност е неуспешен, компилацията се отхвърля, за да се избегне загуба на време и ресурси за по-задълбочено тестване.

Целта „не“ е да се провери цялостната функционалност, а да се определи дали разработчикът е приложил известна рационалност (здрав разум) при създаването на софтуера. Например, ако вашият научен калкулатор дава резултат 2 + 2 = 5! Тогава няма смисъл да се тестват разширени функционалности като sin 30 + cos 50.

История и произход на термините

Терминът „тестване с дим“ произхожда от хардуерната и електронната индустрия. Когато инженерите включвали нова платка за първи път, те наблюдавали дали тя започва да дими – незабавен индикатор за фундаментален недостатък. Ако не се появява дим, можело да се продължи с основното тестване. Тази концепция била възприета от софтуерните тестери през 1980-те години на миналия век, за да опише първоначалната проверка на сглобяването.

„Тестване за разумност“, от друга страна, се отнася до проверка на „разумността“ или рационалността на конкретни промени. Терминът набляга на проверката дали софтуерът се държи по разумен и логичен начин след модификации – по същество задавайки въпроса: „Има ли смисъл това?“

Тестване за дим срещу тестване за здрав разум срещу регресионно тестване

Разбирането как тези три вида тестване работят заедно е от решаващо значение за ефективна стратегия за осигуряване на качеството:

  • Тестване на дим е на първо място – проверява дали компилацията е достатъчно стабилна, за да може изобщо да се тества.
  • Тестване за вменяемост следва (когато е приложимо) – това потвърждава, че конкретни промени или поправки работят правилно.
  • Тестване на регресия е най-изчерпателният – гарантира, че новите промени не са нарушили съществуващата функционалност.

Мислете за това като за фуния: Smoke тестването е широкият отвор, който бързо филтрира нестабилните компилации, sanity тестването стеснява фокуса до специфични промени, а регресионното тестване осигурява цялостно покритие на цялата система.

СВЪРЗАНИ СТАТИИ

Реален сценарий: Приложение за електронна търговия

Помислете за уебсайт за електронна търговия, който получава нова версия с магазинping корекция на грешка в количката:

Тест за дим: QA първо проверява дали уебсайтът се зарежда, потребителите могат да влязат, продуктите се показват правилно, търсенето работи и процесът на плащане започва. Това отнема около 15-30 минути.

Тест за здрав разум: След като тестът за дим премине успешно, тестерите се фокусират специално върху магазинаping функционалност на количката – добавяне на артикули, актуализиране на количества, премахване на артикули и проверка на изчисленията. Този целенасочен тест отнема около 30-60 минути.

Ако и двете са успешни, екипът преминава към пълно регресионно тестване, което може да отнеме няколко часа или дни в зависимост от сложността на приложението.

Кога да използвате тест за дим срещу тест за здрав разум

Използвайте тест за дим, когато:

  • Нова софтуерна компилация е внедрена в тестовата среда
  • Трябва бързо да проверите критични функционалности като вход, навигация и поток от данни
  • Определяне дали компилацията е достатъчно стабилна за по-нататъшно детайлно тестване
  • Интегриране в CI/CD конвейери за автоматизирана проверка на изграждането

Използвайте тест за здрав разум, когато:

  • Внедряват се малки промени в кода, корекции на грешки или подобрения на функциите
  • Проверка дали конкретни промени работят по предназначение
  • Сглобката вече е относително стабилна от предишни тестове за дим

Предимства и ограничения

Предимства

  • Бързо идентифициране на критични проблеми: И двата метода бързо идентифицират проблеми, които биха спрели тестването.
  • Ресурсна ефективност: Екипите не губят време за детайлно тестване на фундаментално счупени компилации.
  • Ранно откриване на дефекти: Откриването на проблеми в ранен етап от цикъла намалява общите разходи за отстраняване.
  • По-бързи цикли на освобождаване: Ефективен контролерping позволява по-бърза итерация и внедряване.

Ограничения

  • Ограничено покритие: Нито един от двата типа тестове не осигурява цялостно покритие на цялото приложение.
  • Може да пропусне скрити грешки: Проблеми с интеграцията или гранични случаи може да останат неоткрити.
  • Не е заместител на пълното тестване: Те служат като бързи филтри, а не като заместители на регресионното тестване.

Най-добри практики за внедряване

За тестване на дим:

  • Автоматизирайте тестовете за дим и ги интегрирайте във вашия CI/CD конвейер за всяка компилация.
  • Фокусирайте пакета от тестове за дим само върху критични функционалности – не го оставяйте да стане твърде голям.
  • Актуализирайте тестовете за дим, когато се добавят или променят критични функции.

За тестване за здрав разум:

  • Винаги преглеждайте документацията за промени, преди да създавате сценарии за тестване на разумността.
  • Фокусирайте усилията за тестване върху променените области и непосредствено съседни функционалности.
  • Използвайте техники за проучвателно тестване, за да откриете неочаквани проблеми.

Често срещани грешки, които трябва да се избягват

  • Объркване на двата вида тестове: Тестването за дим е широкообхватно и повърхностно; тестването за здрав разум е тясно и задълбочено.
  • Пропусниping тестване с дим, за да спестите време: Това често води до загуба на усилия при нестабилни компилации.
  • Прекалено изчерпателни тестове за дим: Това обезсмисля целта на бързата проверка.
  • Продължаване след неуспехи: Ако някой от типовете тест е неуспешен, спрете и отстранете проблемите, преди да продължите.

Препоръчителни инструменти за тестване на дим и здрав разум

  • Selenium Уебдрайвер: Индустриален стандарт за автоматизация на тестване на уеб приложения
  • TestNG/JUnit: Тестови рамки за организиране и изпълнение на автоматизирани тестове
  • JenkinsДействия в /GitHub: CI/CD инструменти за автоматизирано изграждане и изпълнение на тестове
  • Cypress: Модерна, лесна за разработчици рамка за цялостно тестване
  • Postman/Бъдете сигурни: Инструменти за API тестване за backend димни тестове

Въпроси и Отговори

Тестването за разумност проверява дали последните промени в кода или корекции на грешки работят правилно, без да се създават нови проблеми. Например, след актуализиране на модул за вход, тестерите потвърждават, че удостоверяването на потребителя и пренасочването все още функционират както се очаква.

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

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

Тестването за разумност се извършва след малки промени в кода, корекции или корекции на грешки, за да се валидира целевата функционалност. То гарантира, че модификациите работят по предназначение, преди да се инвестира време в регресионно или интеграционно тестване.

Димните тестове трябва да се изпълняват след всяко ново внедряване на компилация. Те проверяват дали основните функции работят и дали приложението е достатъчно стабилно, за да продължи с обширно автоматизирано или ръчно тестване.

Да, рамки за автоматизация и CI/CD системи могат да работят едновременно. Smoke тестовете валидират стабилността на компилацията, докато sanity тестовете потвърждават точността на функционалността, ускорявайки готовността за пускане в гъвкави среди.

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

Съвременните рамки за автоматизация използват маркиране или модулни тестови пакети. Smoke тестовете са част от CI/CD конвейери за бърза валидация, докато sanity тестовете са селективни скриптове, задействани след целенасочени актуализации на кода.

Тестването за разумност е по-ефективно, защото изкуственият интелект може да анализира промени в кода и данни за минали дефекти, за да предвиди кои функционалности вероятно ще бъдат засегнати, като по този начин интелигентно фокусира усилията за валидиране.

Обобщете тази публикация с: