- Тестирање јединица наспрам интеграцијског тестирања вс функционалног тестирања
- Шта је тестирање јединица?
- Шта је тестирање интеграције. ?
- Јединично тестирање наспрам интеграцијско тестирање
- Функционално тестирање
- Закључак
- Препоручена литература
Детаљно поређење јединичног, интеграцијског и функционалног тестирања:
За било коју софтверску апликацију, и тестирање јединица, као и тестирање интеграције, је веома важно јер свако од њих користи јединствени процес за тестирање софтверске апликације.
Али било који или чак оба не могу заменити функционално тестирање у било ком тренутку.
Тестирање јединица наспрам интеграцијског тестирања вс функционалног тестирања
Тестирање јединица значи тестирање појединачних модула апликације у изолацији (без икакве интеракције са зависностима) да потврдите да код ради како треба.
Тестирање интеграције значи проверу да ли различити модули добро функционишу када се комбинују заједно као група.
Функционално тестирање значи тестирање дела функционалности у систему (може да ступа у интеракцију са зависностима) да би се потврдило да код ради праве ствари.
Функционални тестови су повезани са тестовима интеграције, међутим, они означавају тестове да проверите функционалност целе апликације са целим кодом који ради заједно, што је скоро тест супер интеграције.
Тестирање јединица узима у обзир проверу једне компоненте система, док тестирање функционалности разматра проверу рада апликације у односу на предвиђену функционалност описана у спецификацији системских захтева. С друге стране, тестирање интеграције разматра проверуинтегрисани модули у систем.
И, што је најважније, да бисте оптимизовали повраћај улагања (РОИ), ваша база кода треба да има што више јединичних тестова, мање тестова интеграције и најмањи број функционалних тестова.
Ово је најбоље илустровано у следећој тестној пирамиди:
Тестове јединица је лакше писати и брже се извршавају. Време и напор за имплементацију и одржавање тестова се повећавају од јединичног тестирања до функционалног тестирања као што је приказано у горњој пирамиди.
Пример:
Хајде да разумемо ове три врсте тестирања са сувише поједностављеним примером.
Нпр. . За функционалан мобилни телефон, главни потребни делови су „батерија“ и „сим картица“.
Пример тестирања јединице – Батерија се проверава за њен век трајања, капацитет и друге параметре. Сим картица се проверава да ли је активирана.
Пример тестирања интеграције – Батерија и сим картица су интегрисане, односно састављене да би се покренуо мобилни телефон.
Функционално Пример тестирања – Функционалност мобилног телефона се проверава у смислу његових карактеристика и коришћења батерије, као и могућности сим картице.
Видели смо пример у лаички услови.
Сада, хајде да сада узмемо технички пример странице за пријављивање:
Скоро свака веб апликација захтева корисника/купаца да се пријаве. За то свака апликација мораимају страницу „Пријава“ која има ове елементе:
- Налог/корисничко име
- Лозинка
- Дугме за пријаву/пријаву
За тестирање јединица, следећи могу бити тест случајеви:
- Дужина поља – поља корисничког имена и лозинке.
- Вредности поља за унос треба да буду важеће.
- Дугме за пријаву је омогућено тек након што су важеће вредности (Формат и по дужини) унете у оба поља.
За тестирање интеграције, следећи могу бити тест случајеви:
- Корисник види поруку добродошлице након што унесе важеће вредности и притисне дугме за пријаву.
- Корисник треба да буде навигиран на страницу добродошлице или почетну страницу након ваљаног уноса и клика дугме Логин.
Сада, након што се заврши тестирање јединице и интеграције, да видимо додатне тестне случајеве који се разматрају за функционално тестирање:
- Проверава се очекивано понашање, тј. да ли корисник може да се пријави кликом на дугме за пријаву након што унесе важеће корисничко име и вредност лозинке.
- Да ли постоји порука добродошлице која се појављује након успешне пријаве?
- Да ли постоји порука о грешци која би требало да се појави на неважећој пријави?
- Да ли постоје сачувани колачићи сајта за поља за пријаву?
- Може ли неактивирани корисник да се пријави?
- Да ли постоји линк 'заборављена лозинка' за кориснике који су заборавили своје лозинке?
Има много више таквих случајева који долазе доум функционалног испитивача док обавља функционално тестирање. Али програмер не може да преузме све случајеве док прави тестне случајеве јединица и интеграције.
Дакле, постоји много сценарија који тек треба да се тестирају чак и након тестирања јединица и интеграције.
Сада је време да испитамо јединично, интеграцијско и функционално тестирање једно по једно.
Шта је тестирање јединица?
Као што име говори, овај ниво укључује тестирање 'Јединице'.
Овде јединица може бити најмањи део апликације који се може тестирати, било да је то најмања појединачна функција, метода итд. Програмери софтвера су ти који пишу случајеве јединичних тестова. Овде је циљ да се усклади са захтевима и очекиваним понашањем јединице.
У наставку је неколико важних тачака о тестирању јединица и његовим предностима:
- Тестирање јединице се ради пре Интеграционог тестирања од стране програмера софтвера користећи технике тестирања беле кутије.
- Тестирање јединица не само да проверава позитивно понашање, тј. тачан излаз у случају исправног уноса, већ и грешке које се јављају са неважећим уносом.
- Проналажење проблема/бугова у раној фази је веома корисно и смањује укупне трошкове пројекта. Пошто се тестирање јединица обавља пре интеграције кода, проблеми који се налазе у овој фази могу се врло лако решити, а њихов утицај је такође веома мањи.
- Тест јединица тестира мале делове кода или појединачнефункције тако да су проблеми/грешке пронађене у овим тест случајевима независни и не утичу на друге тестне случајеве.
- Још једна важна предност је то што случајеви јединичних тестова поједностављују и олакшавају тестирање кода. Дакле, постаје лакше решити проблеме иу каснијој фази јер треба тестирати само најновију измену кода.
- Тестирање јединица штеди време и трошкове, може се поново користити и лако се одржава.
ЈУнит (Јава оквир), ПХПУнит (ПХП оквир), НУнит (.Нет фрамеворк) итд. су популарни алати за тестирање јединица који се користе за различите језике.
Шта је тестирање интеграције. ?
Тестирање интеграције је тестирање интеграције различитих делова система заједно. Два различита дела или модула система се прво интегришу, а затим се врши интеграцијско тестирање.
Циљ интеграционог тестирања је да се провери функционалност, поузданост и перформансе система. систем када је интегрисан.
Тестирање интеграције се врши на модулима који се прво тестирају на јединици, а затим тестирање интеграције дефинише да ли комбинација модула даје жељени излаз или не.
Тестирање интеграције може или обављају независни тестери или програмери.
Постоје 3 различита типа приступа тестирању интеграције. Хајде да укратко продискутујемо сваки од њих:
а) Приступ интеграције Великог праска
У овом приступу, сви модули или јединице су интегрисани и тестирани као целина у једном тренутку. Ово се обично ради када је цео систем спреман за интеграцијско тестирање у једном тренутку.
Не бркајте овај приступ тестирања интеграције са тестирањем система, тестира се само интеграција модула или јединица, а не цео систем као што се ради у тестирању система.
Главна предност приступа Великог праска је да се све интегрисано тестира у једном тренутку.
Једна главна недостатак је то што постаје тешко идентификовати кварове.
Пример: На доњој слици, јединица 1 до јединица 6 су интегрисане и тестиране коришћењем приступа Великог праска.
б) Приступ одозго надоле
Интеграција јединица/модула се тестира од врха до нивоа корак по корак.
прва јединица се тестира појединачно писањем тест СТУБС-а. Након овога, нижи нивои се интегришу један по један док се последњи ниво не састави и тестира.
Приступ одозго надоле је веома органски начин интеграције јер је у складу са начином на који се ствари дешавају у стварности окружење.
Једина забринутост код овог приступа је да се главна функционалност тестира на крају.
ц) На дну- Приступ навише
Јединице/модули се тестирају од дна до највишег нивоа, корак по корак, све док сви нивои јединица/модула нису интегрисании тестирани као једна јединица. Стимулаторни програми под називом ДРИВЕРС се користе у овом приступу. Лакше је открити проблеме или грешке на нижим нивоима.
Главни мана овог приступа је што се проблеми вишег нивоа могу идентификовати само на крају када све јединице имају је интегрисан.
Јединично тестирање наспрам интеграцијско тестирање
Пошто смо имали довољно дискусије о тестирању јединица и интеграцијском тестирању, хајде да брзо прођемо кроз разлике између та два у следећој табели:
Тестирање јединица | Тестирање интеграције |
---|---|
Тестира једну компоненту целог система тј. тестира јединицу у изолацији. | Тестира компоненте система које раде заједно, тј. тестира сарадњу више јединица. |
Брже за извршавање | Може да ради споро |
Нема спољне зависности. Било која спољна зависност се исмева или угаси. | Захтева интеракцију са спољним зависностима (нпр. база података, хардвер, итд.) |
Једноставно | Сложено |
Проводи програмер | Проводи тестер |
То је врста тестирања беле кутије | То је је врста тестирања црне кутије |
Обавља се у почетној фази тестирања, а затим се може извршити било када | Мора се извршити након тестирања јединице и пре тестирања система |
Јефтиноодржавање | Скупо одржавање |
Почиње од спецификације модула | Почиње од спецификације интерфејса |
Јединица тестирање има уски опсег јер само проверава да ли сваки мали део кода ради оно што је намењен. | Има шири опсег пошто покрива целу апликацију |
Исход тестирања јединице је детаљна видљивост кода | Исход интеграције тестирање је детаљна видљивост структуре интеграције |
Откријте проблеме унутар функционалности само појединачних модула. Не открива грешке у интеграцији или проблеме у целом систему. | Откријте грешке које настају када различити модули интерагују један са другим да би формирали целокупни систем |
Функционално тестирање
Техника тестирања црне кутије, где се тестира функционалност апликације како би се генерисали жељени излаз при давању одређеног улаза, назива се „Функционално тестирање“.
У нашим процесима тестирања софтвера, ми урадите ово писањем тест случајева према захтевима и сценаријима. За било коју функционалност, број написаних тест случајева може да варира од једног до више.
Закључак
Сва ова три типа тестирања су у корелацији.
Да би се постигла пуна покривеност, потребно је да има тестове јединица за путање/линије кода, функционалне и интеграцијске тестове како би се уверио да су 'јединице'раде заједно кохезивно.
Надам се да би вам овај чланак дао јасну идеју о јединичном, интеграцијском и функционалном тестирању заједно са њиховим разликама, иако има много више од ових облика тестирања!!