structural testing tutorial what is structural testing
Този изчерпателен урок за структурно тестване обяснява какво е структурно тестване, неговите типове, какво е тестване на контролния поток и графика на контролния поток, нива на покритие и др .:
Бързото търсене в Google на някои от най-скъпите софтуерни грешки остави съзнанието ми - 500 милиарда долара. Да, това е колко скъпо може да получи грешка. Четенето на всичко, свързано със загубени животи в транспортната и здравната индустрия поради софтуерна грешка, също може да бъде ужасяващо.
Въпреки че грешките в кода не винаги са толкова екстремни, когато включват загуба на големи суми пари и животи, единственият ключов извод тук, който се опитваме да предадем, е, че не може да се пренебрегне тестването.
Когато тестовете се извършват често през SDLC, това ни позволява да улавяме грешки, които ще се нуждаят от много повече време за отстраняване след изпращането на продукта.
Важното е избраните от нас видове софтуерно тестване. Има няколко от тях, включително функционални, структурни и базирани на промени тестове.
Този урок също обяснява типовете структурно тестване. Научете как да правите тестване на мутации, тестване на парчета, тестване на данни в детайли с примери и обяснения.
Какво ще научите:
- Защо е важно тестването на софтуер
- Какво е структурно тестване
- Видове структурно изпитване
- Предимства и недостатъци на структурно изпитване
- Структурни тестове Най-добри практики
- Заключение
Защо е важно тестването на софтуер
В допълнение към спестяването на пари и избягването на бедствия като споменатите по-горе случаи, има още няколко причини, които да оправдаят важността на тестването.
По-долу са посочени някои причини:
# 1) За да се гарантира спазването на предвидените изисквания преди да започнете да изграждате проект. Заинтересованите страни (например разработчици и клиенти) трябва да се споразумеят за всички аспекти на решението / продукта / софтуера, които са необходими за изграждане на проект.
Тестването включва проверка дали са изпълнени софтуерните изисквания. Разработчикът или компанията, участваща в изграждането на решението, също печелят добра репутация за проектиране на такова висококачествено решение, което се управлява от eclat код.
# 2) Проверява дали кодовата функция работи по предназначение. Тестването също така включва проверка на функционалността на софтуера и в случай на неизправност, той трябва да бъде отстранен по време на ранните фази на SDLC (жизнен цикъл на разработката на софтуер).
# 3) Проверява за производителност: Например, за идентифициране на общото време, изминало при изпълнение на кода. Ако използваме няколко За цикли в нашия код ще отнеме много време, за да получим предвидената продукция и понякога може дори да изчака.
# 4) Помага за постигане на по-добро потребителско изживяване. Потребителите няма да се радват да използват софтуер, който не функционира правилно, греши или е „твърде бавен“. Потребителите вероятно ще получат нетърпение и ще отпаднат, използвайки софтуера. Тестването ни дава по-добра възможност да гарантираме, че потребителите могат лесно да използват нашите продукти.
# 5) Проверява за мащабируемост. Разработчикът трябва да се стреми към изграждане на софтуер, който може да се мащабира.
# 6) Проверява за уязвимости в кода. Тестването ни дава възможност да търсим уязвимости в сигурността, Например, код, който може да компрометира ИД (Лична информация), което е важен приоритет за GDPR.
В тази статия ще се съсредоточим върху един вид тестване, т.е. Структурно изпитване . Както подсказва името, това е свързано със структурата на кода. Това е различно от това, което споменахме по-рано, че тестването помага да се определят аспекти като производителност на код, функционалност и сигурност.
безплатно приложение за карти за iphone и android
Структурно изпитване срещу други видове изпитване
Има много видове софтуерно тестване. както и да е СПРИ СЕ (Международен съвет за квалификация за тестване на софтуер), дефинира 4 основни типа тестване на софтуер, а именно
- Функционални
- Нефункционален
- Структурни
- Въз основа на промяна
Разликите могат да бъдат обяснени по-долу:
Функционално тестване: Това включва проверка на функционалността на софтуера спрямо предвидените изисквания. Данните от теста се използват като вход. Също така проверяваме дали изходът е както се очаква.
Нефункционално тестване : Това включва процес на тестване, за да се анализира колко добре работи софтуерът, например, броя потребители, с които може да се справи едновременно.
Структурно изпитване: Този тип тестване се основава на структурата на кода. Например, ако кодът има за цел да изчисли средната стойност на четните числа в масив, тогава тестването, базирано на структурата, би се интересувало от „стъпките, които водят до изчисляване на средната стойност“, а не дали крайният изход е правилна числова стойност.
Да предположим, че трябва да проверим дали сме дефинирали кода, който разграничава четните числа от нечетните числа. Тук може да имаме условно изражение, например, ако елемент от масив се дели на два без остатък, ако (arr [i]% 2 === 0) тогава числото може да се каже като четно число.
Структурното тестване се извършва от същите хора, които пишат кода, както го разбират най-добре.
Тестване въз основа на промяна : Това включва тестване на ефектите от извършване на промени в кода и след това гарантиране, че направените промени са внедрени. Той също така гарантира, че промените в кода не го нарушават.
Какво структурно тестване не е
По-рано споменахме, че тестването на базата на структура се отнася до структурата на кода. Имайте предвид, че тук се занимаваме с действителния код. Ние не проверяваме спрямо изискванията или дори тестваме входовете спрямо очакваните резултати. В този момент ние не се занимаваме с функционалност, потребителски опит или дори производителност.
Какво е структурно тестване
Следователно тестването, базирано на структура, може да бъде определено като вид софтуерно тестване, което тества структурата на кода и предвидените потоци. Например, проверка на действителния код за аспекти като правилното изпълнение на условни изрази и дали всеки израз в кода е изпълнен правилно. Известно е също като структурно базирано тестване.
За да извършим този тип тестване, трябва добре да разберем кода. Ето защо това тестване обикновено се извършва от разработчиците, които са написали кода, както го разбират най-добре.
Как да се извърши структурно изпитване
За да тестваме различни аспекти на кода, първо трябва да разберем контролните потоци.
Тестване на контролния поток
Това е извличане на тестове от контролните потоци на кода (реда, в който се изпълняват инструкции, функции и различни аспекти на кода).
Процес на тестване на контролния поток:
График на контролния поток
Процесът на контролния поток започва чрез създаване на визуално представяне на различни раздели на кода, което ни помага да определим пътищата, които могат да бъдат следвани по време на изпълнението.
Тези визуални представяния са известни като графики на контролния поток (CFG) и имат няколко компонента като възли, ръбове, пътеки, кръстовища и точки за вземане на решения. Графиката може да бъде създадена ръчно или автоматично, където софтуерът се използва за извличане на графиката от изходния код.
Нека разгледаме тези компоненти по-долу:
# 1) Блок на процеса
Тази част се използва за представяне на секция от код, която се изпълнява последователно. Това означава, че той се изпълнява по един и същи начин всеки път и няма решения или „разклоняване“, които трябва да бъдат направени. Състои се от възли с един вход и изход.
Пример за процесния блок:
[изображение източник ]
Блокът на процеса не е съществена част от контролния поток и в резултат трябва да бъде тестван само веднъж.
# 2) Точки за решение
Това са някои ключови компоненти в контролния поток на кода. В рамките на тези възли се вземат решения. Това обикновено се прави чрез сравнение и контролният поток се променя в зависимост от решението. Тази част от CFG се състои от един възел с поне 2 изхода.
Решението, взето тук, може да бъде условни отчети като, ако-иначе (които имат два възможни изхода) и отчети за случаи (които могат да имат повече от два изхода).
[изображение източник ]
В горната диаграма има точка за вземане на решение (от условната „възраст = 18“), която е последвана от опции „да“ или „не“.
# 3) Точки на свързване
От горната диаграма можем лесно да идентифицираме точките на свързване до мястото, където точките за вземане на решение се свързват. Точките на свързване могат да имат много входни пътища, но могат да имат само един изходен път.
Най-добри практики за графики за контрол на потока:
Има няколко неща, които трябва да се отбележат при изграждането на графики на контролния поток:
- Опитайте се възможно най-много, за да поддържате CFG прост. Можем да направим това, като комбинираме части, които могат да се считат за „по-малко значими“, например, процесни блокове.
- Уверете се, че в точките за вземане на решения се взема само едно решение. В по-сложните CFG има „последици“, които настъпват след вземането на решението. В горния ни пример можем също да добавим, че ако дадено лице е на 18 години или повече, то то отговаря на условията и трябва да плати за билет. Ако не са, тогава влизането е безплатно. Решението „друго“ трябва да „пропусне“ няколко възли и всички тези стъпки трябва да бъдат показани в нашия CFG.
След като дефинирахме своя CFG, сега е време да преминем към следващата стъпка в процеса на тестване на контролния поток, т.е.да определим степента, до която ще тестваме кода.
Определяне колко да тествате:
Колко от изходния код трябва да бъде тестван? Трябва ли да тестваме всеки възможен път? Опитът да обхване всички пътища в нашите тестове е практически невъзможен. Трябва да намерим средна позиция, за да определим колко тестове можем да направим.
Ако кажем, че се стремим да тестваме 50% от нашия код, това може да означава, че ще дефинираме всички изпълними кодове и ще тестваме поне половината от тях. Въпросът, който възниква тук обаче, е „трябва ли тогава да дефинираме всички възможни изпълними пътища?“
Това отново може да е практически невъзможно. По-добрият подход може да бъде насочен към тестване на 50% от пътищата, които можем да идентифицираме във всеки раздел на кода.
Съществуват различни нива на покритие, а именно покритие на изявление, клон и път. Ще ги разгледаме накратко по-късно.
Създаване на тестови случаи:
Следващата стъпка е създаването на тестови случаи, които ще използваме. Тестовите случаи в структурно базирано тестване се основават на следните фактори:
- Изпълнимите инструкции.
- „Решенията“, които трябва да бъдат взети.
- Възможните пътища, които могат да бъдат следвани.
- Условията, които трябва да бъдат изпълнени (те могат да бъдат множествени или булеви).
Горните фактори ни дават представа за видовете тестови случаи, които трябва да създадем. Можем да използваме и инструмент за генериране на структурни тестове. Ако нашият код е на езика за програмиране C, можем да използваме PathCrawler за генериране на тестов код. Друг инструмент, който можем да използваме, е fMBT.
Изпълнение на тестовите случаи:
Тук трябва да стартираме тестовете. Можем да въведем вход или данни, за да проверим как го изпълнява кода, и след това да проверим дали получаваме очакваните резултати. Например, въведете масив в извикване на функция, за да наблюдавате, че резултатите, които получаваме след прелитане през него, или за да проверите дали точките за вземане на решения вземат правилните решения.
Анализиране на резултатите:
В тази част всичко, което правим, е да проверим дали получаваме правилните резултати след изпълнението. Например, ако въведем масив, където всички стойности са над 18, тогава трябва да имаме всички точки за вземане на решение, водещи до „допустимо“.
Предположения за контрол на потока
Важно е да се отбележи, че за извършване на тестване на контролния поток има няколко предположения, които се правят. Те включват:
- Единствените налични грешки са тези, които могат да повлияят на контролния поток.
- Всички променливи, функции и елементи са точно дефинирани.
Нива на покритие в контролните потоци
Както споменахме по-рано, има различни нива на покритие при тестване на контролния поток.
Нека ги разгледаме накратко.
# 1) Покритие на изявлението
При структурното тестване изпълнимите кодови инструкции играят жизненоважна роля, когато става въпрос за определяне на методите за проектиране на тестовете.
Ние се стремим да постигнем 100% покритие, което означава, че всеки изпълним оператор е тестван поне веднъж. Колкото по-голямо е покритието, толкова по-малко е вероятността да пропуснете грешките и грешките.
Тук се изисква да се използват тестови случаи. Данните, за които се нуждаем, са да гарантират, че всеки изпълним оператор в блок код се изпълнява поне веднъж.
разлика между системното тестване и теста за приемане от потребителя
# 2) Покритие на клона
Това ниво на покритие включва тестване на точките в клоновете на CFG (където се вземат решения). Резултатите са логически. Дори ако се използва оператор за превключване и има множество резултати, по същество всеки блок за случай е сравнение на двойка стойности.
Подобно на покритието на извлеченията, трябва да се стремим към 100% покритие на клонове. За да постигнем това, трябва поне веднъж да тестваме всеки резултат на всяко ниво на решение. Тъй като имаме работа с булеви резултати, тогава трябва да се стремим към провеждането на поне 2 теста на секция от код.
# 3) Покритие на пътя
Това ниво на покритие е по-задълбочено в сравнение с покритие на решения и изявления. Целта тук е да „откриете“ всички възможни пътища и да ги тествате поне веднъж. Това може да отнеме изключително много време. Може обаче да помогне за откриването на грешки или грешки в нашия код или дори аспекти, които трябва да дефинираме, например, потребителско въвеждане.
Видове структурно изпитване
[изображение източник ]
Мутационно тестване
Мутационното тестване е техника за тестване, базирана на грешки, при която различни варианти на софтуерно приложение се тестват спрямо тестовия набор от данни.
>> Вижте този урок за задълбочен поглед върху Тестване на мутации.
Тестване на парчета
Slice Based Testing (SBT) може да се дефинира като техника за тестване на софтуер, която се базира филийки - изпълними части на програмата или групи изявления, които засягат някои стойности в определени точки на интерес в програмата, например, части, където променливите са дефинирани или изходът на група отчети.
Как да направя нарязване
Пример за нарязване в SBT: Код за отпечатване на четни и нечетни числа (Python)
num_list = range(1,12) even_nums = [] odd_nums = [] for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Има два начина да разгледате парче: Като следвате пътя на интересуваща променлива или частта от кода, която влияе на резултата.
В нашия пример, ако разгледаме изхода на нечетните числа, можем да проследим частта от кода, която ни води до този изход.
В критериите за нарязване, дадени от Марк Вайзер (който е въвел SBT), парче се дефинира с помощта на тази формула: S (v, n) , където, v се отнася до въпросната променлива ( например, където е дефинирана променлива), и н е изявлението за интерес ( например, където е даден изход), и С означава парче.
В горния пример, за да получим среза, започваме от изхода на ред 10, който става наш н . Нашата променлива е където .
Така че нашите критерии за нарязване са:
S(v,n) = S(var,10)
Нашата грижа са изявленията, които ни водят до резултата.
Това са:
10,9,8,4,3,1
И така, нашият дял в този код е:
num_list = range(1,12) odd_nums = [] for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Видове тестване на парчета
Има два вида SBT: статичен и динамичен
# 1) Динамично тестване на парчета
Примерът за SBT, обяснен по-горе, където разгледахме твърденията, които влияят върху отпечатването на нечетните числа, е динамичен SBT. Нашата грижа е много специфична. Ние трябва да се фокусираме само върху това, което пряко влияе върху конкретната продукция.
Изпълняваме кода и използваме тестови данни, за да гарантираме, че той работи както трябва. Можем да увеличим обхвата до диапазон (1,50), например, за да видите дали все още генерира само нечетни числа. Dynamic SBT е известен също като тестване за валидиране.
# 2) СтатичноТестване на парчета
За разлика от Dynamic SBT, фокусът на статичното тестване е върху определена променлива. Ако мислим за нашия изход в горния пример като където , можем да проследим среза, който го засяга като 10,9,8,7,6,5,4,3,2,1
Това е основно целият кодов блок! Тук проверяваме дали кодът е правилен по отношение на синтаксиса и изискванията и не го изпълняваме. Статичният SBT е известен също като тестване за проверка.
Важно е да се отбележи, че динамичният SBT е „по-малък“ в сравнение със статичния си аналог. Освен това е по-конкретно.
Най-добри практики / насоки за тестване на парчета
Критериите за нарязване трябва да се определят от:
- Изявления, където стойностите са дефинирани или присвоени, както и преназначена стойност.
- Изявления, при които се получават стойности извън програмата, например, чрез потребителски вход.
- Изявления, които отпечатват изхода / връщат изхода.
- Последното изявление на програмата, например, извикване на функция, което може да дефинира стойности или да предоставя стойности на аргументи
Предимствата на тестването на срезове включват:
- Тъй като в SBT работим само със специфични области на интерес, това улеснява ефективното генериране на тестови пакети.
- Пътят се определя от зависимости в кода, което е по-добре от използването покритие на пътя.
- Със SBT е по-лесно да намерите грешки в изходния код.
Недостатъците на тестовете, базирани на срезове, включват:
- Ако използваме динамично тестване при тестване на голяма кодова база, ще ни трябват много изчислителни ресурси.
- Ако използваме статично тестване, може да пропуснем грешки.
Тестване на потока от данни
Тестването на потока от данни може да се определи като техника за тестване на софтуер, която се основава на стойностите на данните и тяхното използване в програма. Той проверява дали стойностите на данните са били използвани правилно и дали те генерират правилните резултати. Тестването на потока от данни помага да се проследят зависимостите между стойностите на данните по определен път на изпълнение.
Аномалии на потока от данни
Аномалиите на потока от данни са просто грешки в софтуерна програма. Те се класифицират съответно на типове 1, 2 и 3.
Нека да се задълбочим в тях по-долу:
Тип 1: Дефинира се променлива и й се присвоява стойност два пъти.
Примерен код: Python
lst_1 = [1,2,3,4] lst_1 = [5,6,7,8] for var in lst_1: print(var)
Lst_1 се дефинира и му се присвояват две различни стойности. Първата стойност просто се игнорира. Аномалии от тип 1 не водят до неуспех на програмата.
Тип 2: Стойността на променлива се използва или се позовава, преди да бъде дефинирана.
Примерен код: Python
for var in lst_1: print(var)
Цикълът по-горе няма стойности за итерация. Аномалии от тип 2 причиняват неуспех на програмата.
Тип 3: A генерира се стойност на данните, но никога ли не се използва.
Примерен код: Python
lst_1 = [1,2,3,4] lst_2 = [5,6,7,8] for var in lst_1: print(var)
Променливата lst_2 не е посочен. Аномалии от тип 3 може да не причинят отказ на програмата.
Процес на тестване на потока от данни
За да дефинираме зависимостите между стойностите на данните, трябва да дефинираме различните пътища, които могат да бъдат следвани в програма. За да направим това ефективно, трябва да вземем назаем от друг тип структурно изпитване, известен като тестване на контролен поток .
Етап 1) Начертайте графика на контролния поток
Трябва да нарисуваме графика на контролния поток, която е графично представяне на пътищата, които бихме могли да следваме в нашата програма.
Примерен код: Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)
В горния пример с код членът трябва да получи отстъпка, ако покани посетител.
Графика на контролния поток (CFG):
Стъпка 2) Разгледайте дефиницията и използването на променливи и стойности на данни.
Променливата в програмата се дефинира или използва. В CFG имаме променливи на всеки възел. Всеки възел се именува според типа променлива, в който се помещава. Ако променлива е дефинирана в определен възел, тя създава дефиниращ възел. Ако променлива се използва на възел, тя създава възел за използване.
Ако разгледаме променливите разходи в CFG, това са възлите за определяне и използване:
Възел | Тип | Код |
---|---|---|
1 | Дефиниране на възел | цена = 20 |
5 | Възел за използване | сметка = цена -1 |
7 | Възел за използване | сметка = цена |
Стъпка # 3) Определете пътищата за използване на дефиниция.
Има два типа пътища за използване на дефиниция: du пътеки и постояннотокови пътеки. du path са пътища на дефиниция, които започват с възел за дефиниция и завършват с възел за използване. Това важи за пътя по отношение на променливата цена по-горе.
Пример за постоянен път, път за изчистване на решение, е пътят по отношение на променливата на сметката, както е показано по-долу:
Възел | Тип | Код |
---|---|---|
5 | Дефиниране на възел | сметка = цена -1 |
7 | Дефиниране на възел | сметка = цена |
8 | Възел за използване | печат (сметка) |
dc path има повече от един дефиниционен възел, въпреки че все още завършва на възел за използване.
Стъпка # 4) Създайте тестовия пакет.
Това е добавяне на вход. Имайте предвид, че трябва да имаме различен тестов пакет за всяка променлива. Тестовият пакет ще ни помогне да идентифицираме аномалии на потока от данни.
Видове тестване на потока от данни
Има два вида - Статично и динамично .
Статично означава, че преминаваме през кода и CFG, за да идентифицираме аномалии в данните, без да го изпълняваме. Динамично означава, че ние действително идентифицираме конкретните пътища и след това създаваме тестови пакети, за да го тестваме в опит да „хванем“ аномалии, които може да сме пропуснали по време на статично тестване.
Предимства и недостатъци на тестването на потока от данни:
- Тестването на потока от данни е идеално за идентифициране на аномалии на потока от данни, което го прави много ефективен метод за структурно тестване.
- Недостатъкът му е, че е необходимо да се познава добре езика, използван за писане на кода, за да се използва тестване на потока от данни. Освен това отнема много време.
Предимства и недостатъци на структурно изпитване
Нека сега открием причините, поради които структурните тестове са чудесен подход, и да разгледаме и някои негови недостатъци.
Предимства:
- Позволява задълбочено тестване на кода, което води до минимални грешки. Структурното тестване дава възможност софтуерът да бъде щателно тестван. Различните нива на покритие - изявление по изявление, всяка точка на решение и път имат за цел постигане на 100% покритие, което значително намалява шансовете грешките да останат неоткрити.
- Способността да се автоматизира . Има няколко инструмента, които можем да използваме за автоматизиране на тестването. Това ще ни помогне да постигнем максимално покритие на кода и за по-кратко време в сравнение с ръчното тестване.
- Това води до по-високо качество на кода . Разработчиците имат шанс да проучат структурата и внедряването на кода и да поправят всички грешки, както и да подобрят тези аспекти. Позволява ни да имаме предвид страхотната структура, докато пишем следващите части на кода или внедряваме останалите функции.
- Това може да се направи през всяка фаза на SDLC - Структурните тестове могат да се извършват във всяка фаза на SDLC, без да се чака завършването на разработката на 100%. Това улеснява идентифицирането на грешки на ранен етап и по този начин спестява много време в сравнение с тестването след завършване на разработката.
- Помага да се отървете от мъртъв код . Това може да се разглежда като „допълнителен“ или ненужен код, например, код, който ще изчисли резултат, но никога не го използва в нито едно от следващите изчисления.
- Ефективност - Тъй като разработчиците, които пишат кода, са същите тези, които го тестват, няма нужда да се включват други хора като QA.
Недостатъци:
- Разработчиците, които извършват структурно тестване, трябва да имат задълбочено разбиране на езика . Други разработчици и QA, които не са добре запознати с езика, не могат да помогнат при тестването.
- Може да стане доста скъпо от гледна точка на време и пари . Необходими са много време и ресурси, за да се направи ефективно тестването.
- Това води до забавяне на доставката на функции . Това е така, защото разработчиците са изтеглени от изграждането на софтуер, за да направят тестване.
- Мащабирането е проблем, особено когато участват големи приложения . Голямо приложение се равнява на прекалено голям брой маршрути за покриване. Постигането на 100% покритие става невъзможно.
- Може да има пропуснати случаи и маршрути , например, в случай, когато характеристиките не са напълно развити или тепърва ще бъдат разработени. Това означава, че трябва да се комбинира с други видове тестване, като тестване на изискванията (където проверяваме спрямо посочените функции, които трябва да бъдат изградени).
Структурни тестове Най-добри практики
Някои от факторите, които изискват внимание при провеждане на структурно тестване, са следните:
- Ясно маркирайте и назовете тестовете . Ако някой друг трябва да проведе тестовете, той трябва да може лесно да ги открие.
- Преди да подобрите кода, т.е. като го рефакторирате и оптимизирате за използване в различни среди, се уверете, че неговата структура и поток са идеални.
- Провеждайте тестове поотделно . По този начин е лесно да се идентифицират грешки и да се поправят. От друга страна, е по-малко вероятно да пропуснем грешки или пътища в резултат на припокривания в кодови секции, блокове или пътища.
- Генерирайте тестове, преди да направите промени . Тестовете са необходими, за да се проведат според очакванията. По този начин, ако нещо се счупи, е лесно да се проследи и отстрани проблемът.
- Съхранявайте отделно тестовете за всяка секция или блок код . По този начин, ако има промени по линията, не е необходимо да променяме много тестове.
- Отстранете грешките, преди да продължите с тестването . Ако установим някакви грешки, по-добре е да ги поправим, преди да пристъпим към тестване на следващия раздел или блок от код.
- Никога не пропускайте структурните тестове с предположението, че QA все пак ще извърши тестване. Дори ако грешките в началото могат да изглеждат незначителни, кумулативно, те могат да доведат до бъги код, който никога не може да постигне предназначението си.
Често задавани въпроси за структурно базирано тестване
Тук ще разгледаме често задаваните въпроси, когато става въпрос за структурно базирано тестване.
В # 1) Каква е разликата между функционалното изпитване и структурното изпитване?
Отговор: Функционалното тестване е вид софтуерно тестване, основаващо се на предвидените изисквания в SRS (Спецификации на софтуерните изисквания). Обикновено се прави в наддаване, за да се открият несъответствия между спецификациите в SRS и начина на работа на кода. Структурното тестване се основава на вътрешната структура на кода и неговото прилагане. Необходимо е задълбочено разбиране на кода.
В # 2) Какви са видовете структурно изпитване?
двойно свързан списък клас c ++
Отговори на типовете включват:
- Тестване на потока от данни
- Тестване на мутации
- Тестване на контролния поток
- Тестване на срезове
В # 3) Какво е пример за структурно тестване?
Отговор: Ето пример, показващ покритие на извлечения:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();
Размерът на покритието, който получаваме, зависи от тестовите данни, които предоставяме като вход (дали отговаря на условията сума> 0).
В # 4) Каква е разликата между тестването на потока от данни и тестването на контролния поток?
Отговор: И тестването на потока от данни, и тестването на контролния поток използват графики на контролния поток. Единствената разлика е, че при тестването на контролния поток ние се фокусираме върху пътищата, генерирани от кода, докато при тестването на потока от данни се фокусираме върху стойностите на данните, тяхната дефиниция и използване в рамките на пътищата, идентифицирани в рамките на програма.
В # 5) За какво се използва тестването на потока от данни?
Отговор: Тестването на потока от данни е идеално за идентифициране на аномалии при използването на стойности на данни в пътеки в графика на контролния поток, например, една променлива, на която е присвоена стойност два пъти, променлива, която е дефинирана и не е използвана, или променлива, която е използвана или е посочена и не е дефинирана.
В # 6) Каква е разликата между нарязването и нарязването на кубчета при тестване на софтуер?
Отговор: Нарязването означава да се съсредоточите върху определени изявления за интерес в дадена програма и да игнорирате останалите. Нарязването на кубчета е, когато идентифицираме един отрязък, който има грешен вход, и след това го нарязваме, за да проследим правилното поведение.
В # 7) Каква е разликата между тестване на мутации и покритие на кода?
Отговор: При тестване на мутации ние разглеждаме броя на убитите мутанти като процент от общия брой мутанти. Покритието на кода е просто количеството код, което е тествано в програма.
Заключение
В този урок разгледахме задълбочено структурно тестване - какво е то, какво не, как да го направим, видове покритие, предимства и недостатъци, най-добри практики и дори някои често задавани въпроси относно този тип тестване на софтуера.
Все още има толкова много, че можем да научим за структурно базирано тестване. В бъдещи уроци ще изследваме покритие на кода (изявление, решение, клон и път), типове структурни тестове (мутация, поток от данни и базирани на срезове) и дори инструментите, които можем да използваме за автоматизиране на тези тестови процеси.
Важно е да се отбележи, че няма тип или подход за тестване на софтуер, който да е 100% ефективен. Винаги е препоръчително да се комбинират различни видове тестове и подходи.
Например, структурното изпитване се допълва значително от изпитването на изискванията, тъй като може да има функции, които може да не са били разработени по времето, когато се провеждат тестовете на базата на структура.
Техниките за структурно тестване се основават на грешките, които човешките програмисти допускат, когато пишат код. Предполага се, че програмистът е експерт и знае какво кодира, но от време на време греши.
Различните видове структурни тестове, които разгледахме - тестване на мутации, базирано на срезове и тестване на потока на данни могат да бъдат проследени до грешки като използване на грешен оператор (тестване на мутации) или препращане към променлива преди използването му (тестване на потока от данни) .
Препоръчително четене
- Урок за деструктивно изпитване и безразрушително тестване
- Функционално тестване срещу нефункционално тестване
- Какво е техника за изпитване на базата на дефекти?
- Урок за тестване на накисване - Какво е тестване на накисване
- Урок за тестване на SOA: Методология за тестване за архитектурен модел на SOA
- Тестване на натоварване с уроци за HP LoadRunner
- Какво е гама тестване? Финален етап на изпитване
- Урок за тестване на DevOps: Как DevOps ще повлияе на QA тестването?
- Какво е тестване за съответствие (тестване за съответствие)?