Меню

Тестване на дим срещу тестване на разумността: Разлика с примери

smoke testing vs sanity testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Разгледайте подробно разликите между тестовете за дим и тестовете за здравословно състояние с примери:

В този урок ще научим какво е тестване за здравословно състояние и дим при тестване на софтуер. Също така ще научим ключовите разлики между тестовете за здрав разум и дим с прости примери.

Повечето пъти се бъркаме между значението на тестването за здравословно състояние и димното тестване. На първо място, тези две тестове са много “ различно ”И се извършват през различни етапи от тестовия цикъл.

Тестване на дим и тестове за здравословно състояние

Какво ще научите:

Изпитване на разумността

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

Следователно бих определил,

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

Не изпадаме ли всички в ситуация, когато трябва да се отпишем за ден-два, но компилацията за тестване все още не е пусната?

въпроси за интервю за автоматизиране на тестове за опитни

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

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

здравословно тестване

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

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

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

Моят опит

Опит на тестване за здравословно състояние

От моята 8+ години кариера в софтуерното тестване, 3 години работех в Пъргав методолог y и това беше времето, когато използвах предимно тест за здравословно състояние.

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

Следователно по-долу са някои от ключовите насоки, които използвах при такива ситуации:

# 1) Седнете с мениджъра и екипа на разработчиците, когато те обсъждат изпълнението, защото трябва да работят бързо и следователно не можем да очакваме да ни обясняват отделно.

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

# две) Тъй като ви липсва време, докато екипът за разработки работи по внедряването, можете да запишете тестовите случаи приблизително в инструменти като Evernote и др. Но не забравяйте да ги напишете някъде, за да можете да ги добавите по-късно към инструмента за тест.

# 3) Поддържайте вашето тестово място готово според внедряването и ако смятате, че има някакви червени флагове като създаване на конкретни данни, ако тестовото поле ще отнеме време (а това е важен тест за изданието), след това вдигнете тези флагове незабавно и информирайте вашия мениджър или PO за блокадата на пътя.

Само защото клиентът иска възможно най-скоро, това не означава, че QA ще излезе, дори ако е половин тест.

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

# 5) Когато екипът за разработки тества в своя край, опитайте се да се сдвоите с тях (наречен dev-QA сдвояване) и направете основен кръг на самата им настройка, това ще помогне да се избегне компилацията, ако основната реализация е неуспешна .

# 6) Сега, когато имате компилация, първо тествайте бизнес правилата и всички случаи на употреба. Можете да запазите тестове като валидиране на поле, навигация и т.н. за по-късно.

# 7) Каквито и грешки да намерите, направете си бележка за всички и се опитайте да ги докладвате заедно на разработчиците, вместо да докладвате поотделно, защото ще им е лесно да работят на куп.

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

# 9) Това е най-важната част и всъщност последната стъпка от вашата стратегия за тестване на здравословното състояние - „Когато съставяте имейл за издание или документа, споменете всички тестови случаи, които сте изпълнили, грешките, намерени с маркер на състоянието и ако е останало нещо непроверени го споменават с причините ' Опитайте се да напишете ясна история за вашето тестване, която ще разкаже на всички за това, което е тествано, проверено и кое не.

Следвах това религиозно, когато използвах това тестване.

Позволете ми да споделя моя собствен опит:

# 1) Работихме върху уебсайт и той използваше изскачащи реклами въз основа на ключовите думи. Рекламодателите полагаха оферти за определени ключови думи, които имаха екран, проектиран за същото. Стойността на офертата по подразбиране се показваше като $ 0,25, която оферентът може дори да промени.

Имаше още едно място, където тази оферта по подразбиране се показваше и тя можеше да бъде променена и на друга стойност. Клиентът дойде с искане да промени стойността по подразбиране от $ 0,25 на $ 0,5, но той спомена само очевидния екран.

По време на нашата дискусия за мозъчна атака забравихме (?) За този друг екран, защото той не беше използван много за тази цел. Но докато тествах, когато пуснах основния случай на наддаването да е $ 0,5 и проверих край до край, установих, че cronjob за същото се проваля, защото на едно място намира $ 0,25.

Съобщих за това на екипа си и направихме промяната и я доставихме успешно същия ден.

# две) В рамките на същия проект (споменат по-горе) бяхме помолени да добавим малко текстово поле за бележки / коментари за наддаване. Това беше много просто изпълнение и ние се ангажирахме да го доставим същия ден.

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

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

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

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

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

По-долу са дадени няколко разлики между двете:


S. Не.		Тестване на регресия


Изпитване на разумността
7Това тестване е по време, планирано за седмици или дори месец (месеци).

Това обхваща предимно 2-3 дни макс.

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

Това не е планирано тестване и се извършва само когато има времева криза.

4За това тестване е създаден подходящо проектиран набор от тестови случаи.

Възможно е не всеки път да е възможно да се създадат тестовите случаи; обикновено се създава груб набор от тестови случаи.

5Това включва задълбочена проверка на функционалност, потребителски интерфейс, производителност, тестване на браузър / ОС и т.н., т.е. всеки аспект на системата е регресиран.

Това включва основно проверка на бизнес правила, функционалност.

6Това е широко и задълбочено тестване.

Това е широко и плитко тестване.

Стратегия за тестване на мобилни приложения

Тестване на здравословното състояние на мобилното приложение

Сигурно се чудите защо тук споменавам конкретно за мобилните приложения?

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

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

Следват някои указания, които да ви помогнат да извършите успешно това тестване на „мобилно приложение“:

# 1) На първо място, анализирайте въздействието на версията на операционната система върху внедряването с вашия екип.

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

# две) В горната бележка анализирайте и за моделите телефони, т.е. има ли функции на телефона, които ще повлияят на изпълнението? Прилагането на промяна на поведението с GPS ли е? Променя ли се поведението на внедряването с камерата на телефона? и т.н. Ако установите, че няма въздействие, избягвайте тестването на различни модели телефони.

# 3) Освен ако няма промени в потребителския интерфейс за внедряването, бих препоръчал да запазите тестването на потребителския интерфейс с най-малък приоритет, можете да информирате екипа (ако искате), че потребителският интерфейс няма да бъде тестван.

# 4) За да спестите време, избягвайте тестването в добри мрежи, защото е очевидно, че внедряването ще работи както се очаква в силна мрежа. Бих препоръчал да започнете с тестване в 4G или 3G мрежа.

# 5) Това тестване трябва да се извърши за по-малко време, но се уверете, че сте направили поне един полеви тест, освен ако това не е само промяна на потребителския интерфейс.

# 6) Ако трябва да тествате матрица от различна операционна система и тяхната версия, бих ви предложил да го направите по интелигентен начин. Например, изберете най-ниската, средната и най-новата двойка OS-версии за тестване. Можете да споменете в документа за изданието, че не всяка комбинация е тествана.

# 7) На подобен ред, за теста за здравословно изпълнение на потребителския интерфейс, използвайте малки, средни и големи размери на екрана, за да спестите време. Можете също да използвате симулатор и емулатор.

Предпазни мерки

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

В такива случаи липсата на писмена комуникация, тестова документация и пропуски са доста често срещани.

За да сте сигурни, че няма да станете жертва на това, уверете се, че:

  • Никога не приемайте компилация за тестване, докато не получите писмено изискване, споделено от клиента. Случва се клиентите да комуникират промени или нови внедрения устно или в чат или обикновена 1 подложка в имейл и очакват от нас да третираме това като изискване. Принудете клиента си да предостави някои основни функционални точки и критерии за приемане.
  • Винаги правете груби бележки за вашите тестови случаи и грешки, ако нямате достатъчно време да ги напишете добре. Никога не ги оставяйте без документи. Ако има малко време, споделете го с вашия водач или екип, така че ако нещо липсва, те лесно да го посочат.
  • Ако на вас и на екипа ви липсва време, уверете се, че грешките са отбелязани в съответното състояние в имейл? Можете да изпратите пълния списък с грешки до екипа и да накарате разработчиците да ги маркират по подходящ начин. Винаги дръжте топката в корта на другия.
  • Ако имате Рамка за автоматизация готови, използвайте това и избягвайте да правите Ръчно тестване , по този начин за по-малко време можете да покриете повече.
  • Избягвайте сценария на „освобождаване за 1 час“, освен ако не сте 100% сигурни, че ще можете да доставите.
  • Не на последно място, както беше споменато по-горе, изгответе подробен имейл за съобщение, в който се съобщава какво е тествано, какво е пропуснато, причини, рискове, кои грешки са отстранени, какво е „Latered“ и т.н.

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

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

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

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

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

В светлината на това, как QA ще се увери, че основните функционалности работят добре?

Отговорът на това ще бъде изпълнението на a Тестване на дим .

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

След като тестовете бъдат маркирани като димни тестове (в тестовия пакет), само тогава компилацията се приема от QA за задълбочено тестване и / или регресия. Ако някой от тестовете за дим се провали, компилацията се отхвърля и екипът на разработчика трябва да отстрани проблема и да пусне нова компилация за тестване.

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

Това тестване обикновено се използва при тестване на интеграция, тестване на системата и тестване на ниво на приемане. Никога не третирайте това като заместител на действителното цялостно тестване . Състои се както от положителни, така и от отрицателни тестове в зависимост от изпълнението на компилацията.

Примери за тестване на дим

Това тестване обикновено се използва за интеграция, приемане и Тестване на системата .

В кариерата си като QA винаги приемах компилация само след като бях направил тест за дим. Така че, нека да разберем какво е тест за дим от гледна точка на всички тези три теста, с някои примери.

# 1) Изпитване за приемане

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

В този тест първият и най-важен тест за дим е да се провери основната очаквана функционалност на изпълнението. По този начин трябва да проверите всички реализации за конкретната компилация.

Нека вземем следните примери като изпълнения, направени в компилация, за да разберем димните тестове за тях:

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

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

# 2) Тестване на интеграцията

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

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

Нека разгледаме следните примери за внедряване на интеграция за това тестване:

  • Изпълнена интеграция на модули за маршрути и спирки.
  • Реализира интеграцията на актуализация на състоянието на пристигане и отразява същото на екрана за спирки.
  • Реализирана е интеграцията на пълни модули за доставка до функционалността на доставката.

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

# 3) Тестване на системата

Както подсказва самото име, за системно ниво тестването на дим включва тестове за най-важните и често използвани работни потоци на системата. Това се прави само след като цялата система е готова и тествана и това тестване за системно ниво може да се нарече тестване на дим преди регресионно тестване.

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

Това обикновено се прави с помощта на инструменти за автоматизация.

Значение в методологията SCRUM

В днешно време проектите почти не следват методологията Waterfall при изпълнението на проекти, най-вече всички проекти следват Agile и SCRUM само. В сравнение с традиционния метод за водопад, тестването на дим отдава високи почитания в SCRUM и Agile.

Работих 4 години в SCRUM . И тъй като знаем, че в SCRUM спринтовете са с по-кратка продължителност и следователно е от изключителна важност да се направи това тестване, така че неуспешните компилации да могат незабавно да бъдат докладвани на екипа за разработка и да бъдат отстранени.

Следват някои за вкъщи относно важността на това тестване в SCRUM:

  • Извън двуседмичния спринт полувремето се разпределя на QA, но понякога изгражданията на QA се забавят.
  • При спринтовете е най-добре за отбора да се докладват проблемите на ранен етап.
  • Всяка история има набор от критерии за приемане, следователно тестването на първите 2-3 критерия за приемане е равно на тестване на дим на тази функционалност. Клиентите отказват доставката, ако един критерий е неуспешен.
  • Само си представете какво ще се случи, ако екипът за разработка ви достави компилацията за 2 дни, а за демонстрацията остават само 3 дни и се натъкнете на основна функционална повреда.
  • Средно, спринтът има истории, вариращи от 5-10, следователно, когато е дадена компилация, е важно да се уверите, че всяка история е изпълнена, както се очаква, преди да приеме компилацията в тестване.
  • Когато цялата система трябва да бъде тествана и регресирана, спринт е посветен на дейността. Две седмици може би малко по-малко, за да тествате цялата система, затова е много важно да проверите най-основните функционалности, преди да започнете регресията.

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

Изпитването на дим е пряко свързано с изпитването за приемане на сгради (НДНТ).

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

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

Цикъл за изпитване на дим

Следващата блок-схема обяснява цикъла на изпитване на дим.

След като компилацията бъде внедрена в QA, следваният основен цикъл е, че ако тестът за дим премине, компилацията се приема от екипа на QA за по-нататъшно тестване, но ако не успее, компилацията се отхвърля, докато докладваните проблеми не бъдат отстранени.

Тестов цикъл

Цикъл за изпитване на дим

най-добрият шпионин на мобилен телефон за android

Кой трябва да направи тест за дим?

Коя икона

Не целият екип участва в този тип тестване, за да се избегне загубата на време на всички QA.

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

Понякога, когато проектът е мащабен, група от QA може също да извърши това тестване, за да провери за всякакви шоустопъри. Но това не е така в случая на SCRUM, защото SCRUM е плоска структура без ръководители или мениджъри и всеки тестер има свои отговорности към своите истории.

Следователно отделните QA провеждат това тестване за историите, които притежават.

Защо трябва да автоматизираме тестовете за дим?

Това тестване е първият тест, който се прави на компилация, издадена от екипа (ите) за разработка. Въз основа на резултатите от това тестване се извършва допълнително тестване (или компилацията се отхвърля).

Най-добрият начин да направите това тестване е да използвате инструмент за автоматизация и да планирате пускането на димния пакет при стартиране на нова компилация. Може би си мислите защо да го правя „Автоматизирате пакета за тестване на дим“?

Нека разгледаме следния случай:

Да кажем, че сте на седмица от излизането си и от общо 500 тестови случая, вашият пакет за тест за дим се състои от 80-90. Ако започнете да изпълнявате всички тези 80-90 тестови случаи ръчно, представете си колко време ще ви отнеме? Мисля 4-5 дни (минимум).

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

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

За този проект имах 800 тестови случая и 250 бяха димни тестове. С използването на селен можем лесно да автоматизираме и да получим резултатите от тези 250 тестови случая за 3-4 часа. Това не само ни спести времето, но ни показа възможно най-скоро за шоустопърите.

Следователно, освен ако не е невъзможно да се автоматизира, използвайте помощта на автоматизацията за това тестване.

Предимства и недостатъци

Нека първо разгледаме предимствата, тъй като има какво да предложи в сравнение с малкото недостатъци.

Предимства:

  • Лесен за изпълнение.
  • Намалява риска.
  • Дефектите се идентифицират на много ранен етап.
  • Спестява усилия, време и пари.
  • Работи бързо, ако е автоматизиран.
  • Най-малко интеграционни рискове и проблеми.
  • Подобрява цялостното качество на системата.

Недостатъци:

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

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

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

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

Разлика между тестовете за дим и здрав разум

Повечето пъти се бъркаме между значението на тестването за здравословно състояние и димното тестване. На първо място, тези две тестове са много “ различно ”И се извършва по време на различни етапи от тестовия цикъл.

S. Не.Тестване на дим

Изпитване на разумността

1 Тестването на дим означава да се провери (основно), че изпълненията, направени в компилация, работят добре.Тестът за разумно състояние означава, че новодобавените функционалности, грешки и т.н. работят добре.
две Това е първото тестване на първоначалната компилация.Готово, когато компилацията е относително стабилна.
3 Извършено при всяка компилация.Съставено на стабилни компилации след регресия.

Следва схематично представяне на техните разлики:

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

ИЗПИТВАНЕ НА ДИМ

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

ИЗПИТВАНЕ НА САНИТОРНОСТТА

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

Надявам се, че сте наясно с разликите между тези два огромни и важни типа тестване на софтуер. Чувствайте се свободни да споделите мислите си в раздела за коментари по-долу !!

Препоръчително четене

^