smoke testing vs sanity testing
Детаљно истражите разлике између испитивања дима и испитивања здравствено исправног стања на примерима:
У овом упутству ћемо научити шта је испитивање исправности и тестирање дима у софтверском тестирању. Такође ћемо научити кључне разлике између тестирања здраве памети и дима помоћу једноставних примера.
У већини случајева се збунимо између значења испитивања исправности и испитивања дима. Пре свега, ова два тестирања су начин “ различит “И изводе се током различитих фаза циклуса испитивања.
Шта ћете научити:
- Испитивање разумности
- Моје искуство
- Испитивање исправности против регресијског испитивања
- Стратегија за тестирање мобилних апликација
- Мере предострожности
- Испитивање дима
- Примери испитивања дима
- Значај у СЦРУМ методологији
- Тест дима вс Изградња испитивања прихватљивости
- Циклус испитивања дима
- Ко треба да изврши тест дима?
- Зашто бисмо требали аутоматизовати тестове дима?
- Предности и мане
- Разлика између тестирања дима и разума
- Препоручено читање
Испитивање разумности
Испитивање исправности врши се када као КА немамо довољно времена за покретање свих тест случајева, било да је то случај Функционално тестирање , УИ, ОС или тестирање прегледача.
Стога бих дефинисао,
„Испитивање исправности као извршење теста које се ради да би се додирнула свака примена и њен утицај, али не темељно или детаљно, може укључивати функционално, корисничко сучеље, верзију итд. Тестирање, у зависности од примене и њеног утицаја.“
Зар не паднемо сви у ситуацији када морамо да се одјавимо за дан или два, али верзија за тестирање још увек није објављена?
најбољи софтвер за опоравак података за спољни чврсти диск
Ах да, кладим се да сте се и ви морали суочити са овом ситуацијом барем једном током свог искуства са тестирањем софтвера. Па, суочио сам се с тим јер су моји пројекти били углавном агилни и понекад су од нас тражили да их испоручимо истог дана. Упс, како бих могао да тестирам и пустим изградњу у року од неколико сати?
Понекад сам полудео јер чак и ако је то била мала функционалност, импликације би могле бити огромне. И као шлаг на торти, клијенти понекад једноставно одбију да дају додатно време. Како бих могао да завршим цело тестирање за неколико сати, да проверим сваку функционалност, Бубе и ослободити?
Одговор на све такве проблеме био је врло једноставан, тј. Само коришћење Стратегија испитивања исправности.
Када вршимо ово тестирање модула или функционалности или комплетног система, Тест случајеви за извршење су изабрани тако да ће додирнути све битне делове истог тј. широко, али плитко испитивање.
Понекад се тестирање врши чак и насумично, без тест случајева. Али запамти, Тест здраве исправности треба радити само када вам понестаје времена, никада то немојте користити за редовна издања. Теоретски, ово тестирање је подскуп од Регресија тестирање .
Моје искуство
Од своје 8+ година каријере у тестирању софтвера, 3 године сам радио у Агиле метходолог и и то је било време када сам углавном користио тест здраве исправности.
Сва велика издања била су планирана и извршена на систематичан начин, али понекад се тражило да се мала издања доставе што је пре могуће. Нисмо добили много времена да документујемо тест случајеве, извршимо, направимо документацију о грешкама, извршимо регресију и пратимо цео процес.
Отуда су следећи неки од кључних смерница које сам некада следио у таквим ситуацијама:
# 1) Седите са менаџером и развојним тимом док разговарају о примени, јер морају да раде брзо, па не можемо очекивати да нам објасне одвојено.
Ово би вам такође помогло да стекнете представу о томе шта ће они применити, на које ће то подручје утицати итд., Ово је врло важно учинити, јер понекад једноставно не схватамо импликације и да ли постоји нека функционалност ће бити спутано (у најгорем случају).
#два) Како вам недостаје времена, док развојни тим буде радио на имплементацији, можете примеравати примере отприлике у алатима као што је Еверноте итд. Али обавезно их негде напишите како бисте их касније могли додати у алат за тест случајеве.
# 3) Припремите тестну станицу према имплементацији, а ако сматрате да постоје црвене заставице попут стварања одређених података ако ће тестној површини требати времена (а то је важан тест за издање), одмах подигните те заставице и обавестите свог менаџера или ПО о блокади пута.
Само зато што клијент жели што пре, не значи да ће се КА објавити чак и ако је напола тестиран.
# 4) Договорите се са својим тимом и менаџером да ћете због временских ограничења грешке саопштавати само развојном тиму и формални поступак додавања, означавање грешака у различитим фазама у алату за праћење грешака обавиће се касније како бисте уштедели време .
# 5) Када развојни тим тестира на њиховом крају, покушајте да се упарите с њима (назива се упаривање дев-КА) и направите основни круг на њиховом самом подешавању, ово ће помоћи да се избегне градња у случају да основна имплементација не успе. .
# 6) Сада када имате верзију, прво тестирајте пословна правила и све случајеве употребе. Тестове попут валидације поља, навигације итд. Можете задржати за касније.
# 7) Без обзира на грешке које нађете, забележите их и покушајте да их пријавите програмерима, а не појединачно, јер ће им бити лако да раде на хрпи.
# 8) Ако имате захтев за укупним Тестирање перформанси или тестирање напрезања или оптерећења, а затим се уверите да имате одговарајући оквир за аутоматизацију за исти. Јер је готово немогуће ручно их тестирати здравим тестом.
# 9) Ово је најважнији део, и заиста последњи корак ваше стратегије испитивања здраве исправности - „Када израђујете е-поруку о издању или документ, спомените све тестове које сте извршили, грешке пронађене маркером статуса и ако је нешто остало неиспитан поменути са разлозима ' Покушајте да напишете оштру причу о свом тестирању која ће свима пренети шта је тестирано, верификовано, а шта није.
Религиозно сам то пратио када сам користио ово тестирање.
Дозволите ми да поделим своје искуство:
# 1) Радили смо на веб локацији и она је некада искакала огласе на основу кључних речи. Оглашивачи су давали понуде за одређене кључне речи које су имале екран дизајниран за исте. Подразумевана вредност понуде некада је била приказана као 0,25 УСД, што би понуђач могао чак и да промени.
Било је још једно место где се ова подразумевана понуда приказивала и могла је да се промени и на другу вредност. Клијент је дошао са захтевом да промени подразумевану вредност са 0,25 на 0,5 долара, али је споменуо само очигледан екран.
Током наше дискусије о мозгању, заборавили смо (?) На овај други екран јер он није много коришћен у ту сврху. Али док сам тестирао када сам покренуо основни случај понуде од 0,5 долара и проверавао крај до краја, открио сам да цроњоб за исти није успео јер је на једном месту пронашао 0,25 долара.
Пријавио сам ово свом тиму и извршили смо промену и успешно је доставили истог дана.
#два) У оквиру истог пројекта (горе поменутог) затражено је да додамо мало текстуално поље за напомене / коментаре за надметање. Била је то врло једноставна имплементација и обавезали смо се да ћемо је испоручити истог дана.
Дакле, као што је горе поменуто, тестирао сам сва пословна правила и случајеве употребе око њих и када сам извршио неко тестирање за проверу, открио сам да када сам унео комбинацију посебних знакова као што је, страница се срушила.
Размислили смо и закључили да стварни понуђачи ни у ком случају неће користити такве комбинације. Стога смо га објавили са добро састављеном белешком о том питању. Клијент је то прихватио као грешку, али се сложио с нама да ћемо је касније применити јер је то била озбиљна грешка, али не и претходна.
# 3) Недавно сам радио на пројекту мобилне апликације и имали смо захтев да ажурирамо време испоруке приказано у апликацији према временској зони. Није требало да се тестира само у апликацији већ и за веб услугу.
Док је развојни тим радио на имплементацији, креирао сам скрипте за аутоматизацију за тестирање веб услуга и ДБ скрипте за промену временске зоне ставке испоруке. Ово је спасило моје напоре и могли бисмо постићи боље резултате у кратком трајању.
Испитивање исправности против регресијског испитивања
Доље је дато неколико разлика између њих двоје:
С. Но. | Регресија тестирање | Испитивање разумности |
---|---|---|
7 | Ово тестирање је заказано за недеље или чак месеце. | Ово углавном траје највише 2-3 дана. |
1 | Испитивање регресије врши се да би се потврдило да комплетни поправци система и грешака раде у реду. | Испитивање исправности врши се насумично како би се потврдило да свака функционалност ради како се очекује. |
два | У овом тестирању регресиран је сваки најситнији део. | Ово није планирано тестирање и врши се само када дође до временског ограничења. |
3 | То је добро разрађено и планирано испитивање. | Ово није планирано тестирање и врши се само када дође до временског ограничења. |
4 | За ово тестирање створен је одговарајуће дизајниран пакет тест случајева. | Можда није сваки пут могуће створити тест случајеве; обично се креира груби скуп тест случајева. |
5 | То укључује детаљну верификацију функционалности, корисничког интерфејса, перформанси, тестирања прегледача / ОС-а итд., Тј. Сваки аспект система је регресиран. | То углавном укључује верификацију правила пословања и функционалности. |
6 | Ово је широко и дубоко тестирање. | Ово је широко и плитко тестирање. |
Стратегија за тестирање мобилних апликација
Сигурно се питате зашто овде посебно помињем мобилне апликације?
Разлог је тај што се верзија ОС-а и прегледача за веб или десктоп апликације не разликује много, а посебно су величине екрана стандардне. Али код мобилних апликација, величина екрана, мобилна мрежа, верзије ОС-а итд. Утичу на стабилност, изглед и укратко на успех ваше мобилне апликације.
Стога формулисање стратегије постаје пресудно када ово тестирање обављате на мобилној апликацији, јер један неуспех може вас довести у велике проблеме. Тестирање се мора обавити паметно и са опрезом.
Следе неки напутци који ће вам помоћи да успешно извршите ово тестирање у „мобилној апликацији“:
# 1) Пре свега, са својим тимом анализирајте утицај верзије ОС-а на имплементацију.
Покушајте да пронађете одговоре на питања попут, да ли ће се понашање разликовати у различитим верзијама? Да ли ће имплементација радити на најнижој подржаној верзији или не? Да ли ће бити проблема са перформансама за примену верзија? Да ли постоји нека специфична карактеристика ОС-а која би могла утицати на понашање имплементације? итд.
#два) На горњој белешци, анализирајте и моделе телефона, тј. Да ли постоје неке карактеристике телефона које ће утицати на примену? Да ли се примена промене понашања помоћу ГПС-а? Да ли се понашање имплементације мења са камером телефона? итд. Ако утврдите да нема утицаја, избегавајте тестирање на различитим моделима телефона.
# 3) Ако не постоје промене корисничког интерфејса за имплементацију, препоручио бих да се тестирање корисничког интерфејса задржи са најмањим приоритетом, можете обавестити тим (ако желите) да кориснички интерфејс неће бити тестиран.
# 4) Да бисте уштедели време, избегавајте тестирање на добрим мрежама јер је очигледно да ће примена на јакој мрежи радити како се очекује. Препоручио бих да започнете са тестирањем на 4Г или 3Г мрежи.
# 5) Ово тестирање треба обавити за мање времена, али обавезно обавите најмање један теренски тест, осим ако се не ради само о промени корисничког интерфејса.
# 6) Ако морате да тестирате матрицу различитих ОС-а и њихове верзије, предложио бих вам да то учините на паметан начин. На пример, одаберите најнижи, средњи и најновију верзију ОС верзије за тестирање. У документу о издавању можете напоменути да није тестирана свака комбинација.
# 7) На сличној линији, за тест исправности корисничког интерфејса, користите мале, средње и велике величине екрана како бисте уштедели време. Такође можете да користите симулатор и емулатор.
Мере предострожности
Испитивање исправности врши се када вам недостаје времена, па стога није могуће да покренете сваки тест случај, а што је најважније немате довољно времена да испланирате своје тестирање. Да би се избегле игре кривице, боље је предузети мере предострожности.
У таквим случајевима недостатак писане комуникације, тест документације и пропуштања су прилично чести.
Да бисте били сигурни да нећете постати жртва овога, уверите се да:
- Никада не прихватајте верзију за тестирање док вам клијент не пружи писмени захтев. Дешава се да клијенти промене или нове примене комуницирају усмено или у чету или једноставном линку у е-поруци и очекују да то третирамо као захтев. Присилите свог клијента да пружи неке основне тачке функционалности и критеријуме прихватања.
- Увек направите грубе белешке о својим тест случајевима и грешкама ако немате довољно времена да их уредно напишете. Никада их немојте остављати без докумената. Ако постоји мало времена, поделите га са својим вођом или тимом, тако да ако нешто недостаје могу то лако да истакну.
- Ако вам и вашем тиму недостаје времена, уверите се да су грешке означене у одговарајућем стању у е-поруци? Комплетну листу грешака можете послати тиму и учинити да их програмери на одговарајући начин означе. Увек држите лопту у терену другог.
- Ако имате Оквир за аутоматизацију спремни, користите то и избегавајте да радите МануалТестинг , на тај начин за мање времена можете покрити више.
- Избегавајте сценарио „пуштања за 1 сат“, осим ако нисте 100% сигурни да ћете моћи да испоручите.
- И последње, али не најмање важно, као што је горе поменуто, израдите детаљну е-пошту са саопштењем о томе шта је тестирано, шта је изостављено, разлоге, ризике, које су грешке отклоњене, шта је „закаснело“ итд.
Као КА, требало би да процијените који је најважнији дио имплементације који треба тестирати и који дијелови могу бити изостављени или основно тестирани.
како тестирати веб страницу
Чак и за кратко време, планирајте стратегију о томе како желите да урадите и моћи ћете да постигнете најбоље у датом временском оквиру.
Испитивање дима
Тестирање дима није исцрпно тестирање, али то је група тестова који се извршавају како би се верификовало да ли основне функционалности те одређене грађе раде у реду како се очекивало или не. Ово је и увек треба да буде први тест који се ради на било којој ‘новој’ верзији.
Када развојни тим пусти зграду у КА на тестирање, очигледно није могуће тестирати целокупну израду и одмах проверити да ли нека од имплементација има грешака или је било која радна функционалност покварена.
У светлу овога, како ће КА осигурати да основне функционалности раде у реду?
Одговор на ово биће извођење а Испитивање дима .
Једном када су тестови означени као тестови дима (у пакету тестова), КА тек тада прихвата изградњу за детаљно тестирање и / или регресију. Ако било који од тестова дима не успе, израда се одбија и развојни тим треба да реши проблем и пусти нову верзију на тестирање.
Теоретски, тест дима дефинисан је као испитивање на површини како би се потврдило да је верзија коју развојни тим пружа КА тиму спремна за даље испитивање. Ово тестирање такође изводи развојни тим пре него што остави верзију КА тиму.
Ово тестирање се обично користи за тестирање интеграције, тестирање система и испитивање нивоа прихватљивости. Никада то немојте третирати као замену за стварно тестирање од краја до краја . Састоји се и од позитивних и од негативних тестова, у зависности од имплементације верзије.
Примери испитивања дима
Ово испитивање се обично користи за интеграцију, прихватање и Тестирање система .
У својој КА каријери увек сам прихватао грађу тек након што сам обавио тест дима. Дакле, хајде да схватимо шта је тест дима из перспективе сва ова три испитивања, са неким примерима.
# 1) Испитивање прихватљивости
Кад год се нека конструкција пусти у КА, тестирајте дим у облику Прихватање тестирање треба урадити.
У овом тесту, први и најважнији тест дима је верификација основне очекиване функционалности примене. Овако, требало би да верификујете све примене за ту одређену верзију.
Узмимо следеће примере као имплементације урађене у некој верзији да бисмо разумели тестове дима за оне:
- Примењена је функција пријављивања како би се регистрованим управљачким програмима омогућило успешно пријављивање.
- Примењена је функција контролне табле да би се приказале руте које возач треба да изврши данас.
- Примењена је функционалност приказивања одговарајуће поруке ако за одређени дан не постоје руте.
У горњој верзији, на нивоу прихватљивости, тест дима ће значити да се верификује да основне три имплементације раде у реду. Ако је било која од ове три покварена, КА би требао одбити израду.
# 2) Интеграционо тестирање
Ово тестирање се обично врши када се појединачни модули имплементирају и тестирају. У Испитивање интеграције На овом нивоу се врши тестирање како би се осигурало да све основне интеграције и функционалности од краја до краја раде како треба.
То може бити интеграција два модула или свих модула заједно, па ће сложеност теста дима варирати у зависности од нивоа интеграције.
Размотримо следеће примере имплементације интеграције за ово тестирање:
- Имплементирана интеграција модула руте и стајалишта.
- Имплементирана је интеграција ажурирања статуса доласка и то се одражава на екрану заустављања.
- Имплементирана интеграција комплетног преузимања до модула функционалности испоруке.
У овој верзији, тест дима не само да ће верификовати ове три основне имплементације, већ и за трећу имплементацију, неколико случајева ће верификовати и потпуну интеграцију. Много помаже у откривању проблема који се уводе у интеграцију и оних који развојни тим није приметио.
# 3) Тестирање система
Као што и само име сугерише, на нивоу система, испитивање дима укључује тестове за најважније и најчешће коришћене токове рада система. То се ради тек након што комплетан систем буде спреман и тестиран, а ово тестирање на нивоу система може се назвати и тестирањем дима пре регресионог тестирања.
Пре започињања регресије комплетног система, основне карактеристике од краја до краја тестирају се као део теста на дим. Пакет за тестирање дима за цео систем састоји се од крајњих до крајњих тест случајева које ће крајњи корисници врло често користити.
То се обично ради уз помоћ алата за аутоматизацију.
Значај у СЦРУМ методологији
У данашње време пројекти готово не прате методологију Водопада у реализацији пројеката, углавном сви пројекти прате Агиле и СЦРУМ само. У поређењу са традиционалном методом водопада, тестирање дима високо цени СЦРУМ и Агиле.
Радио сам 4 године у СЦРУМ-у . А као што знамо да су у СЦРУМ-у спринти краћег трајања, па је стога изузетно важно обавити ово тестирање, тако да се неуспеле верзије могу одмах пријавити развојном тиму и такође поправити.
Следе неке одузети о важности овог тестирања у СЦРУМ-у:
- Изван двоседмичног спринта, полувреме се додељује КА-у, али понекад се надоградње КА одлажу.
- У спринтима је за екипу најбоље да се проблеми пријаве у раној фази.
- Свака прича има скуп критеријума прихватљивости, па је стога тестирање прва 2-3 критеријума прихватања једнако тестирању те функционалности на дим. Купци одбацују испоруку ако један критеријум не успе.
- Замислите само шта ће се догодити ако вам је развојни тим испоручио грађу у року од 2 дана, а преостала су само 3 дана за демонстрацију и наиђете на основни квар функционалности.
- У просеку, спринт има приче у распону од 5 до 10, стога је приликом израде важно осигурати да се свака прича примени на очекивани начин пре него што прихвати израду у тестирање.
- Када се комплетан систем треба тестирати и регресирати, спринт је посвећен активности. Дванаест дана можда мало мање за тестирање целог система, па је зато веома важно верификовати најосновније функционалности пре започињања регресије.
Тест дима вс Изградња испитивања прихватљивости
Испитивање дима директно је повезано са испитивањем прихватљивости зграде (БАТ).
У БАТ-у радимо исто тестирање - да бисмо проверили да ли израда није успела и да ли систем ради у реду или не. Понекад се деси да када се креира зграда, уводе се неки проблеми, а када се испоручи, конструкција не функционише за КА.
Рекао бих да је БАТ део провере дима, јер ако систем закаже, како можете као КА прихватити израду за тестирање? Не само функционалности, сам систем мора да функционише пре него што КА настави са дубинским тестирањем.
Циклус испитивања дима
Следећи дијаграм тока објашњава циклус испитивања дима.
Једном када је изградња распоређена на КА, основни циклус је следећи: ако тест дима прође, КА тим прихвата изградњу на даље испитивање, али ако не успе, градња се одбацује док се не реше отклоњени проблеми.
Тест циклус
Ко треба да изврши тест дима?
Није цео тим укључен у ову врсту тестирања како би се избегло губљење времена свих КА-а.
Тестирање дима идеално изводи КА лидер који на основу резултата одлучује да ли ће проследити израду тиму на даље тестирање или ће је одбити. Или у недостатку потенцијалног клијента, КА сами могу такође да изврше ово тестирање.
Понекад, када је пројекат великог обима, група КА такође може да изврши ово тестирање како би проверила има ли изложбених објеката. Али то није случај у случају СЦРУМ-а, јер је СЦРУМ равна структура без потенцијалних клијената или менаџера, а сваки испитивач има своје одговорности према својим причама.
Отуда појединачна КА спроводе ово тестирање за приче које поседују.
Зашто бисмо требали аутоматизовати тестове дима?
Ово тестирање је први тест који је урађен на верзији коју је објавио развојни тим. На основу резултата овог тестирања врши се даље тестирање (или је одбијање израде).
Најбољи начин за ово тестирање је коришћење алата за аутоматизацију и заказивање покретања димног пакета када се креира нова зграда. Можда размишљате зашто бих „Аутоматизовати пакет за тестирање дима“?
Погледајмо следећи случај:
Рецимо да вас дели недељу дана од вашег издања, а од укупно 500 тест случајева, ваш пакет за тестирање дима садржи 80-90. Ако започнете ручно извршавање свих ових 80-90 тест случајева, замислите колико времена ће вам требати? Мислим 4-5 дана (минимум).
Али ако користите аутоматизацију и креирате скрипте за покретање свих ових 80-90 тест случајева, у идеалном случају, они ће се покренути за 2-3 сата и резултате ћете одмах имати са собом. Није ли вам то уштедело драгоцено време и дало вам резултате о уграђивању много мање времена?
Пре пет година тестирао сам апликацију за финансијску пројекцију која је узимала податке о вашој плати, штедњи итд. И пројектовала ваше порезе, штедњу и добит у зависности од финансијских правила. Уз ово, имали смо прилагођавање за земље које зависе од земље и њених пореских правила која су се некада мењала (у коду).
За овај пројекат имао сам 800 случајева, а 250 случајева за дим. Коришћењем селена могли бисмо лако да аутоматизујемо и добијемо резултате тих 250 тестова за 3-4 сата. Не само да нам је уштедело време, већ нам је што пре показао изложбене продавце.
Стога, осим ако је немогуће аутоматизовати, узмите помоћ аутоматизације за ово тестирање.
Предности и мане
Погледајмо прво предности јер он има много тога да понуди у поређењу са својих неколико недостатака.
Предности:
- Једноставно за извођење.
- Смањује ризик.
- Дефекти се идентификују у врло раној фази.
- Штеди напор, време и новац.
- Ради брзо ако је аутоматизовано.
- Најмање интеграционих ризика и проблема.
- Побољшава укупан квалитет система.
Мане:
- Ово испитивање није једнако нити је замена за потпуно функционално испитивање.
- Чак и након што прође тест дима, можда ћете пронаћи бугове сховстоппера.
- Ова врста тестирања је најпогоднија ако можете аутоматизовати, јер се пуно времена троши на ручно извршавање тест случајева, посебно у великим пројектима који имају око 700-800 тест случајева.
Тестирање дима дефинитивно би требало обавити на свакој верзији, јер указује на велике кварове и изложбе у врло раној фази. Ово се односи не само на нове функционалности, већ и на интеграцију модула, решавање проблема и импровизацију. Извођење и добијање тачног резултата је врло једноставан поступак.
Ово тестирање може се третирати као полазна тачка за потпуно функционално тестирање функционалности или система (као целине). Али пре тога, КА тим би требао бити врло јасан у вези са тестовима који се раде као тестови дима . Ово тестирање може умањити напоре, уштедети време и побољшати квалитет система. Заузима врло важно место у спринтима јер је време у спринтима мање.
Ово тестирање се може обавити како ручно, тако и помоћу алата за аутоматизацију. Али најбољи и омиљени начин је коришћење алата за аутоматизацију како бисте уштедели време.
Разлика између тестирања дима и разума
У већини случајева се збунимо између значења испитивања исправности и испитивања дима. Пре свега, ова два тестирања су начин “ различит “И изводи се током различитих фаза циклуса испитивања.
С. Но. | Испитивање дима | Испитивање разумности |
---|---|---|
1 | Испитивање дима значи да се верификује (основно) да имплементације извршене у некој верзији добро функционишу. | Испитивање исправности значи да се потврди да су нове функције, грешке итд. У реду. |
два | Ово је прво тестирање у почетној верзији. | Готово када је израда релативно стабилна. |
3 | Готово у свакој верзији. | Извршено на стабилним верзијама након регресије. |
Следи дијаграмски приказ њихових разлика:
ИСПИТИВАЊЕ ДИМА
- Ово испитивање је настало у хардвер тестирање праксе првог укључивања новог хардвера и сматрајући га успехом ако се не запали и не дими. У софтверској индустрији, ово тестирање је плитки и широк приступ, при чему се тестирају сва подручја апликације без предубоког заузимања.
- Тест дима је написан, било коришћењем писменог скупа тестова или аутоматизованог теста
- Тест дима дизајниран је да летимично додирне сваки део апликације. Плитко је и широко.
- Ово тестирање се спроводи како би се осигурало да ли најважније функције програма раде, али да се не замарају финим детаљима. (Као што је верификација верзије).
- Ово тестирање је уобичајена здравствена контрола до израде апликације пре него што је положите на дубинско тестирање.
ТЕСТИРАЊЕ САНИТЕТА
- Тест здраве исправности је уски регресијски тест који се фокусира на једно или неколико подручја функционалности. Испитивање исправности је обично уско и дубоко.
- Овај тест је обично неписан.
- Овај тест се користи за утврђивање да мали део апликације и даље ради након мање промене.
- Ово тестирање је површно тестирање, оно се изводи кад год је површно тестирање довољно да докаже да апликација функционише у складу са спецификацијама. Овај ниво тестирања је подскуп регресивног тестирања.
- Ово је да би се потврдило да ли су захтеви испуњени или не, проверавањем свих карактеристика по ширини.
Надам се да су вам јасне разлике између ове две огромне и важне врсте тестирања софтвера. Слободно поделите своје мисли у одељку за коментаре испод !!
Препоручено читање
- Најбољи алати за тестирање софтвера 2021. године [КА Тест Аутоматион Тоолс]
- Разлика између тестирања радне површине, клијентског сервера и веб тестирања
- Функционално тестирање вс нефункционално тестирање
- Преузимање е-књиге за тестирање буквара
- Алфа тестирање и бета тестирање (потпун водич)
- Водич за тестирање преносивости са практичним примерима
- Врсте тестирања софтвера: различите врсте испитивања са детаљима
- Функционално тестирање против тестирања перформанси: треба ли то радити истовремено?