what is cyclomatic complexity learn with an example
Цикломатичната сложност е много често срещана дума в общността за развитие. Тази техника се използва главно за определяне на сложността на даден код или функционалност.
Техниката е разработена от MaCabe и помага да се идентифицират по-долу 3 въпроса за програмите / функциите
- Проверява ли се характеристиката / програмата?
- Разбира ли се функцията / програмата от всички?
- Достатъчно надеждна ли е функцията / програмата?
Като QA можем да използваме тази техника, за да определим „нивото“ на нашето тестване. Практика е, че ако резултатът от цикломатичната сложност е повече или по-голям брой, ние считаме, че тази функционалност е от сложен характер и следователно заключаваме като тестер; че частта от кода / функционалността изисква задълбочено тестване.
От друга страна, ако резултатът от цикломатичната сложност е по-малък, ние заключаваме като QA, че функционалността е с по-малка сложност и съответно решаваме обхвата.
Нека отида стъпка по стъпка: първо разберете как се изчислява и след това ще продължим, за да разберем как се определя нивото на тестване.
Какво ще научите:
- Как да изчислим цикломатичната сложност?
- Формула за цикломатична сложност
- Пример за цикломатична сложност
- Как тестерите могат да го използват?
- Сега идва пряк път-
- Препоръчително четене
Как да изчислим цикломатичната сложност?
Изчисляването на CC се върти около 2 концепции
- Възли
- Ръбове
Изявленията в програма са представени като възли, а контролните пътища от един оператор до друг са представени от Edges.
Формула за цикломатична сложност
Формулата за изчисляване на CC е както следва:
CC = E ~ N + 2
най-добрият рекламен блокер за mac chrome -
Където:
E = Брой ръбове
N = Брой възли.
(Има пряк път за изчисляването му, но не сега ...... по-късно ...)
Пример за цикломатична сложност
Нека вземем долния пример, за да го разберем.
Помислете за следната графика на контролния поток:
как да настроите решетка от селен -
Поставих НЕТ точки за идентифициране на възлите и СИН линии за идентифициране на ръбовете:
Така че тук в този пример:
Брой възли (червени точки) = 14
Брой ръбове (сини линии) = 15
Така че цикломатичната сложност = N ~ E + 2 = (14-15) +2 = 3
Как тестерите могат да го използват?
В реалния свят тестерите могат да седят с разработчиците, за да извлекат графиката на контролния поток за даден код. И след като имаме графиката, можем да извлечем сложността, използвайки тази формула. Но историята за тестерите не свършва дотук: - основният момент тук е - каква е ползата от този номер за екипа за тестване?
Е, тестерите могат да използват този номер, за да определят нивото на своето тестване.
На практика има 2 нива на тестване:
- Тестване на дължина
- Изпитване на широчина
Помислете за матрицата по-долу за различни характеристики на всеки модул: -
Тестване на дължина е начин, по който се опитваме да обхванем целия обхват, като избираме важните тестови случаи за всяка функция. Например , в този случай, предположим, че реша да намеря с тестването на дължина, тогава мога да избера -
- Подфункция 1.1 и Подфункция 1.3 за функция 1
- Подфункция 2.2 от функция 2
- Подфункция 3.3 от функция 3
- Подфункция 4.2 и Подфункция 4.3от функция 4
- Подфункция 5.3 от функция 5
Така че тук засягам цялата функция, без да навлизам в изчерпателни подробности за подфункциите.
Сега, ако резултатът от CC е по-голям брой, тогава реша да отида с тестване на широчина, всъщност ще тествам всяка функция заедно с всяка подфункция.
Така че въз основа на вашите текущи изисквания към проекта, надеждност на околната среда, тестерите могат да си сътрудничат заедно с екипа за разработка и да създадат стандарт за идентифициране на нивото и обхвата на тестването. Например -
- Ако CC<=15 – Basic sanity test
- Ако CC е между 16 и 30 - Тестване на дължина
- Ако CC е между 31 и 50 - Тестване на широчина
- Ако CC> 50 - Това е хаотична функционалност и се нуждае от допълнително разлагане
Сега идва пряк път-
Просто пребройте броя на затворените региони и добавете 1 към него.
В нашия пример по-горе - брой затворена област = 2 (попълнено в жълто), така че CC = 2 + 1 = 3
как да отворите json файл
В реалната работа е много трудно да се заключи резултатът, когато даваме изявления като -
- „... .. тази функционалност е много трудна за изпълнение“
Какво имаш предвид под трудно? Сложно, сложно ли е или хаотично?
Как заключихте, че това е трудно?
- „... това трябва да е на разположение до края на деня“
Какво е краят на деня? Краят ви на деня е 19:00, вероятно моят е 18:00?
- „... трябва да направя подробно тестване за това“
Какво е подробно тестване? Няма техника за тестване, наречена „Подробно тестване“
- „... кодът трябва да бъде с добро качество, преди да го внедрим в QA“
Как измервате доброто качество?
Вместо това, ако префразирам изявленията като -
Цикломатичната сложност за кода се изчислява като 75 и според нашите стандарти; тази функционалност е от хаос характер. Следователно препоръчваме по-нататъшното му разлагане.
Над
- „... .. тази функционалност е много трудна за изпълнение“
Функционалността ще бъде внедрена в QA среда до 17:00 ч. CST.
Над
- '.... Това трябва да е на разположение до края на деня'
Тъй като цикломатичната сложност се изчислява като 48, според нашия стандарт ще правим тестване на системите заедно с теста за интеграция и регресия за функцията.
Над
- '.... Трябва да направя подробно тестване за това'
Според Sonar CC е вече 102. Стандартизирали сме CC до 10. Ще внедрим кода, когато подобрим кода, за да направим CC по-малко от 10.
Над
- „... .кодът трябва да е с добро качество, преди да го внедрим в QA“
Каква е разликата между двете твърдения?
Е, разликата тук е измерването. Подкрепих всяко свое изказване с подходящо измерване, което ще помогне на заинтересованите страни да разберат какво точно искам да кажа.
По същия начин използвайте сложността Cyclomatic при тестване на софтуер, за да определите точната мярка на вашите усилия за тестване и можете да го използвате, за да идентифицирате не само обхвата на вашето тестване, но и видовете тестове, които трябва да направите.
Препоръчително четене
- Какво е тестване на компоненти или модули (научете с примери)
- Какво е сравнително тестване (научете с примери)
- Електронна книга за тестване на софтуер
- Какво е тестване за системна интеграция (SIT): Научете с примери
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Изтегляне на eBook за тестване на Primer
- 5 важни диаграми, които тестерите трябва да научат как да използват
- Урок за преглед на TestRail: Научете управление на тестови случаи от край до край