static testing dynamic testing difference between these two important testing techniques
Тестирање је Верификација и валидација . Сви знамо да су потребна 2 Вс да би тестирање било завршено.
У данашњем чланку ћемо осветлити нешто Статичко испитивање . Такође се назива верификација. Сазнаћемо све о томе и посебно ћемо нагласити ово јер Динамичко испитивање често добија максималну пажњу и има безброј чланака који то детаљно описују.
Међутим, ниједна дискусија о статичком испитивању не би била потпуна без објашњења шта значи његово динамичко испитивање. Динамичко тестирање је валидација, а друго „В“.
бесплатни софтвер часовника за рачунаре
Динамичко тестирање је када радите са стварним системом (а не са неким артефактом или моделом који представља систем), пружајући улаз, примајући излаз и упоређујући излаз са очекиваним понашањем. Практичан је рад са системом са намером проналажења грешака.
Током овог процеса разумећемо како следеће две уобичајене заблуде о тестирању нису тачне:
- Тестирање је активност која долази на крају
- Изводе га само тестери, а остали немају никакве везе
Почнимо са брзим упућивањем на в-модел :
- На лева страна В-модела имамо активности које не врши КА тим.
- На десно , имамо неке од њих о којима се брине Дев тим, неке тестере, а неке корисници.
Почнимо са - Прикупљање захтева . Изводи га пословни аналитичар и друго руководство вишег нивоа - излазни документ за ову фазу је документ о пословним захтевима, БРД.
Следећа фаза је Дизајн система . Дизајн система је фаза у којој се пословни захтеви преводе у функционалне захтеве, у ФРД (документ о функционалним захтевима).
Када се догоди превод, Дев тим (који је главни актер у овом кораку) прећи ће на БРД документ корак по корак, страницу по страницу и ред по ред. Иако је примарни циљ испуњавање пословних захтева ради превода, БРД документ се редом прегледава.
Пример: Рецимо да је ово БРД за банкарску веб локацију која је велика по питању безбедности. У БРД-у постоји одељак који говори о правилима лозинке за различите кориснике који креирају рачун на веб локацији за интернет банкарство. Једно од правила је: Корисник не може да користи лозинку коју користи за друге налоге.
Ово није могуће. Јер, веб локација може само предложити како корисник треба да постави акредитиве за пријаву, али не постоји начин, ово ограничење се може наметнути. Дакле, овај захтев није изводљив - другим речима, не може се постићи помоћу софтвера.
Размотримо сада следеће тачке на основу овог примера:
- Како се утврђује да се овај захтев не може градити и да се не може тестирати (другим речима, није изводљив)? Да ли имамо веб локацију банке, а затим постављамо корисничко име и лозинку - и онда схватамо да то није могуће? Не, ми то једноставно заснивамо на нашем прегледу БРД-а и, наравно, неком здравом разуму.
- Да ли тестирамо овај захтев? Свакако, али чисто заснован на теоријском, концептуалном смислу, али не и на стварном АУТ (апликација у тесту).
- Који је физички облик овог теста? -Једноставно читање или формални преглед БРД-а или још формалнија анализа изводљивости пословних захтева.
Враћајући се нашим заблудама:
- Ко врши овај преглед БРД-а? - Углавном развојни тим и други технички тимови који су одговорни за стварање производа. Не тестери.
- Да ли се овај преглед одвија на крају стварања производа? Не, у самој почетној фази развоја пројекта. Отуда, не само крај.
Технике статичког испитивања:
Да резимирамо, статичко тестирање је део верификације софтверског тестирања који следи методе:
- Прегледи докумената
- Валктхроугхс
- Инспекција
- Анализа изводљивости или било који други облик анализе како би се утврдило да ли је софтвер такав какав треба да буде или не
- Код
Да цитирам ЦСТЕ ЦБОК, „Верификација одговара на питање:„ Да ли смо изградили прави систем? “ док се валидације обраћају: „Да ли смо систем изградили исправно?“
Следе све активности статичког испитивања које се дешавају на левој страни В-модела.
| СДЛЦ фаза | Оутпут | Верификује | Глумци |
|---|---|---|---|
| Прикупљање пословних захтева | БРД (документ о пословном захтеву) | Документ о обиму (ако постоји) | |
| Дизајн системских захтева | ФРД (документ о функционалним захтевима) | Прегледа / верификује БРД | Дев, технички тимови |
| Дизајн техничких захтева | ТДД (технички пројектни документ) | Прегледа / верификује ФРД | Дев, технички тимови |
| Дизајн (код) | Код | Прегледа / верификује ТДД. Комплетни преглед, формат итд., Од стране развојног тима, прегледају код | Дев, технички тимови |
Белешка: Ове информације могу се екстраполовати за пројекте који следе било коју развојну методологију јер ће кораци бити мање или више слични.
На десној страни В-модела налази се валидација.
Технике динамичког испитивања:
- Јединствено тестирање
- Испитивање интеграције
- Тестирање система
Фазе јединице, интеграције, система и УАТ су све о стварању тестова који ће се изводити на АУТ током различитих фаза његовог развоја. Иако су тестови усмерени на потврђивање различитих врста захтева, сви су тестови сви исти.
Дакле, било који облик тестирања где имамо тест који треба извршити на АУТ и чији је излаз потребан да би се утврдио исход теста (успешан или не) - то је валидација.
Сад, да ли би било у реду да се уопсти да на десној страни (РХС) В-модела уопште нема верификације? Одговор је не.
Сви тестови који се креирају у свакој фази РХС прегледају се неколико пута током фазе израде / финализације теста. Детаљан поступак прегледа документације за тест је на хттпс://ввв.софтваретестингхелп.цом/тест-доцументатион-ревиевс/
На РХС:
- Програми прегледавају тестове и код у фазама тестирања јединице / интеграције.
- Системски тестови подлежу стручној провери током њихове документације, а по завршетку подвргавају се ревизији од стране развојног тима и пословног аналитичара.
- УАТ тестови подлежу прегледу КА тима као и корисника пре него што УАТ почне.
Закључак
Закључно, статичко испитивање је важна техника испитивања која има облик прегледа пословних захтева, прегледа функционалних захтева, прегледа дизајна, проласка кроз код и прегледа документације за тестирање. То је континуирана активност коју не раде само тестери.
Провера ваљаности, део динамичког тестирања је практичнији и дешава се на самом производу, а не на артефакту или приказу производа. Много формални поступак идентификације тест случаја / стања, разматрања покривености, извршења и пријављивања кварова, све обележавају динамичке методе испитивања.
ка питања за интервју за искусне
Абоут Аутхор: Овај чланак написао је члан СТХ тима Свати С.
Молимо поделите своје коментаре, питања и искуства на тему статичког и динамичког испитивања.
Препоручено читање
- Разлика између тестирања радне површине, клијентског сервера и веб тестирања
- Агиле технике процене: истинска процена у агилном пројекту
- Тестирање црне кутије: продубљени водич са примерима и техникама
- Шта је испитивање усаглашености (испитивање усаглашености)?
- Која је разлика између СИТ и УАТ тестирања?
- Алфа тестирање и бета тестирање (потпун водич)
- Кључне разлике између тестирања црне кутије и тестирања беле кутије
- Разлике између јединственог тестирања, интеграционог тестирања и функционалног тестирања