static testing dynamic testing difference between these two important testing techniques
Тестването е Проверка и валидиране . Всички знаем, че отнема 2 Vs, за да завърши тестването.
В днешната статия ще хвърлим малко светлина върху Статично тестване . Нарича се още Проверка. Ще научим всичко за това и ще обърнем специално внимание на това, защото Динамично тестване често получава максимално внимание и има безброй статии, които го детайлизират.
Никоя дискусия за статичното тестване обаче не би била пълна без обяснение на това какво означава аналогът му динамично тестване. Динамичното тестване е валидиране, а другото „V“.
Динамичното тестване е, когато работите с действителната система (а не с някакъв артефакт или модел, който представлява системата), осигуряващ вход, получаване на изход и сравняване на изхода с очакваното поведение. Това е практическа работа със системата с цел намиране на грешки.
По време на този процес ще разберем как следните две често срещани заблуди относно тестването не са верни:
- Тестването е дейност, която идва в края
- Извършва се само от тестери, а останалите нямат нищо общо
Нека започнем с бърза справка за v-модел :
- На лява страна на V-модела имаме дейности, които не се извършват от екипа за QA.
- На дясна страна , имаме някои от тях, за които се грижи екипът на Dev, някои от тестерите, а други от потребителите.
Нека започнем с - Събиране на изисквания . Извършва се от Business Analyst и други мениджъри от по-високо ниво - изходният документ за тази фаза е документът за бизнес изисквания, BRD.
Следващият етап е Дизайн на системата . Проектирането на системата е фаза, при която бизнес изискванията се превръщат във функционални изисквания, в FRD (документ за функционални изисквания).
Когато се извършва преводът, екипът на Dev (който е основният участник в тази стъпка) ще премине през BRD документа стъпка по стъпка, страница по страница и ред по ред. Въпреки че основната цел е да се използват бизнес изискванията в името на превода, документът BRD се преразглежда на свой ред.
Пример: Кажете, че това е BRD за банков сайт, който е голям за сигурността. В BRD има раздел, който разказва за правилата за пароли за различните потребители, създаващи акаунт в сайта за онлайн банкиране. Едно от правилата е: Потребителят не може да използва парола, която използва за други акаунти.
как да направя makefile c ++
Това не е възможно. Тъй като сайтът може просто да предложи как потребителят трябва да зададе идентификационни данни за вход, но няма начин, това ограничение може да бъде наложено. Така че, това изискване е невъзможно - с други думи, то не може да бъде изпълнено чрез софтуера.
Нека сега разгледаме следните точки въз основа на този пример:
- Как се определя, че това изискване не може да се изгради и затова не може да бъде тествано (с други думи, не е осъществимо)? Имаме ли сайта на банката и след това ли задаваме потребителско име и парола - и след това осъзнаваме, че това не е възможно? Не, ние просто базираме това на нашия преглед на BRD и разбира се на някакъв здрав бизнес смисъл.
- Изпробваме ли това изискване? Разбира се, но изцяло се основава на теоретичния, концептуалния смисъл, но не и на действителния AUT (заявление под тест).
- Каква е физическата форма на този тест? -Обикновено четене или официален преглед на BRD или още по-формален анализ на осъществимостта на бизнес изискванията.
Връщайки се към нашите погрешни схващания:
- Кой извършва този преглед на BRD? - Най-вече разработчиците и други технически екипи, които отговарят за създаването на продукта. Не тестери.
- Този преглед продължава ли в края на създаването на продукта? Не, на най-началния етап от разработването на проекта. Следователно, не само краят.
Техники за статично тестване:
За да обобщим, статичното тестване е частта за проверка на софтуерното тестване, която следва методите на:
- Прегледи на документи
- Разходки
- Инспекция
- Анализ на осъществимостта или друга форма на анализ, за да се определи дали софтуерът е такъв, какъвто трябва да бъде или не
- Преглед на кода
За да цитираме CSTE CBOK, „Проверката отговаря на въпроса:„ Изградихме ли правилната система? “ докато валидирането се обръща: „Създадохме ли системата правилно?“
По-долу са описани всички дейности по статично тестване, които се случват от лявата страна на V-модела.
| SDLC етап | Изход | Проверява | Актьори |
|---|---|---|---|
| Събиране на бизнес изисквания | BRD (документ за бизнес изисквания) | Документ за обхват (ако има такъв) | |
| Проектиране на системни изисквания | FRD (документ за функционални изисквания) | Преглежда / проверява BRD | Dev, Технически екипи |
| Проектиране на технически изисквания | TDD (Технически проект) | Преглежда / проверява FRD | Dev, Технически екипи |
| Дизайн (код) | Код | Преглежда / проверява TDD. Преглед на кода от екипа на разработчиците за пълнота, формат и т.н. | Dev, Технически екипи |
Забележка: Тази информация може да бъде екстраполирана за проекти, следващи всякакви методологии за разработка, тъй като стъпките ще бъдат повече или по-малко подобни.
От дясната страна на V-модела има валидиране.
как да стартирате
Техники за динамично тестване:
- Единично тестване
- Интеграционно тестване
- Тестване на системата
Фазите Unit, интеграция, система и UAT са свързани със създаването на тестове, които да се извършват на AUT по време на различни етапи от неговото развитие. Въпреки че тестовете са насочени към валидиране на различни видове изисквания, всички те са еднакви.
Така че, всяка форма на тестване, при която имаме тест, който трябва да бъде изпълнен на AUT и изходът му е необходим за определяне на резултата от теста (успешен или не) - това е валидиране.
Сега, би ли било добре да обобщим, че от дясната страна (RHS) на V-модела изобщо няма проверка? Отговорът е: Не.
Всички тестове, които се създават на всеки етап от RHS, се преглеждат няколко пъти по време на етапа на създаване / финализиране на теста. Подробният процес на преглед на документацията за теста е на https://www.softwaretestinghelp.com/test-documentation-reviews/
На RHS:
- Тестовете и кодът се преглеждат на етапите на тестване на модул / интеграция от разработчиците.
- Системните тестове се подлагат на партньорска проверка по време на тяхното документиране и след завършване се подлагат на преглед от екипа на разработчиците и бизнес анализатора.
- Тестовете на UAT преминават преглед от екипа на QA, както и от потребителите преди началото на UAT.
Заключение
В заключение, статичното тестване е важна техника за тестване, която е под формата на преглед на бизнес изискванията, преглед на функционалните изисквания, прегледи на дизайна, ръководства за код и преглед на документацията за теста. Това е непрекъсната дейност и не се извършва само от тестери.
Проверка, частта за динамично тестване е по-практическа и се случва върху самия продукт, а не върху артефакт или представяне на продукта. Много официален процес на идентифициране на тестови случаи / състояния, съображения за покритие, изпълнение и докладване на дефекти, всички маркират динамичните методи за тестване.
За автора: Тази статия е написана от член на екипа на STH Swati S.
Моля, споделете вашите коментари, въпроси и опит по темата за статичното и динамичното тестване.
Препоръчително четене
- Разлика между тестване на настолни компютри, клиентски сървър и уеб тестване
- Техники за пъргава оценка: Истинска оценка в гъвкав проект
- Тестване на черна кутия: задълбочен урок с примери и техники
- Какво е тестване за съответствие (тестване за съответствие)?
- Каква е разликата между SIT Vs UAT тестване?
- Алфа тестване и бета тестване (Пълно ръководство)
- Основни разлики между тестване на черна кутия и тестване на бяла кутия
- Разликите между модулното тестване, интегрираното тестване и функционалното тестване