what is cyclomatic complexity learn with an example
Cyklomatická složitost je ve vývojové komunitě velmi časté slovo. Tato technika se používá hlavně k určení složitosti kódu nebo funkčnosti.
Tato technika byla vyvinuta společností MaCabe a pomáhá identifikovat níže uvedené 3 otázky týkající se programů / funkcí
- Je funkce / program testovatelný?
- Rozumí funkci / programu každý?
- Je funkce / program dostatečně spolehlivý?
Jako QA můžeme použít tuto techniku k identifikaci „úrovně“ našeho testování. Je praxí, že pokud je výsledkem cyklomatické složitosti více nebo větší číslo, považujeme tuto část funkce za složitou, a proto ji považujeme za testera; že část kódu / funkce vyžaduje důkladné testování.
Na druhou stranu, pokud je výsledkem cyklomatické složitosti menší počet, usoudíme jako QA, že funkčnost je méně složitá a podle toho rozhodneme o rozsahu.
Dovolte mi jít krok za krokem: nejprve pochopíme, jak se to počítá, a pak přejdeme k pochopení toho, jak je stanovena úroveň testování.
Co se naučíte:
- Jak vypočítat cyklomatickou složitost?
- Vzorec cyklomatické složitosti
- Příklad cyklomatické složitosti
- Jak to mohou testeři použít?
- Nyní přichází zkratka -
- Doporučené čtení
Jak vypočítat cyklomatickou složitost?
Výpočet CC se točí kolem 2 konceptů
- Uzly
- Hrany
Příkazy v programu jsou reprezentovány jako uzly a řídicí cesty z jednoho příkazu do druhého jsou reprezentovány hranami.
Vzorec cyklomatické složitosti
Vzorec pro výpočet CC je následující:
CC = E ~ N + 2
Kde:
E = počet hran
N = počet uzlů.
(Existuje výpočetní zkratka, ale ne nyní …… později…)
Příklad cyklomatické složitosti
Abychom tomu porozuměli, vezměme si níže uvedený příklad.
Zvažte níže uvedený graf toku řízení:
bezplatná alternativa k rychlým knihám pro malé firmy
Umístil jsem SÍŤ tečky k identifikaci uzlů a MODRÝ řádky k identifikaci hran:
Tady v tomto příkladu:
Počet uzlů (červené tečky) = 14
Počet hran (modré čáry) = 15
Cyklomatická složitost = N ~ E + 2 = (14-15) +2 = 3
Jak to mohou testeři použít?
V reálném světě mohou testeři sedět s vývojáři a odvodit graf toku řízení pro danou část kódu. A jakmile máme graf, můžeme pomocí tohoto vzorce odvodit složitost. Tím ale příběh pro testery nekončí: - zde je hlavní bod - jaké je použití tohoto čísla pro testovací tým?
Testeři mohou toto číslo využít k určení úrovně svého testování.
V praxi existují 2 úrovně testování:
- Testování délky
- Šířka testování
Zvažte níže uvedenou matici pro různé funkce libovolného modulu: -
Testování délky je způsob, kterým se snažíme pokrýt celý rozsah výběrem důležitých testovacích případů pro každou funkci. Například , v tomto případě předpokládejme, že zvolím implikovat testování délky, pak mohu vybrat -
- Dílčí funkce 1.1 a Dílčí funkce 1.3 pro funkci 1
- Dílčí funkce 2.2 z funkce 2
- Dílčí funkce 3.3 z funkce 3
- Dílčí funkce 4.2 a Dílčí funkce 4.3 z funkce 4
- Dílčí funkce 5.3 z funkce 5
Tady se tedy dotýkám celé funkce, aniž bych zacházel do vyčerpávajících podrobností dílčích funkcí.
Nyní, pokud je výsledkem CC větší číslo, pak se rozhodnu pro testování šířky, budu vlastně testovat každou funkci spolu s každou dílčí funkcí.
Takže na základě vašeho aktuálního požadavku na projekt, spolehlivosti prostředí, mohou testeři spolupracovat s vývojovým týmem a vytvořit standard pro identifikaci úrovně a rozsahu testování. Například -
- Pokud je CC<=15 – Basic sanity test
- Pokud je CC mezi 16 a 30 - délkovým testováním
- Pokud je CC mezi 31 a 50 - testování šířky
- Pokud CC> 50 - Je to chaotická funkčnost a vyžaduje další rozklad
Nyní přichází zkratka -
Stačí spočítat počet uzavřených oblastí a přidat k nim 1.
V našem příkladu výše - počet uzavřené oblasti = 2 (vyplněný žlutě), takže CC = 2 + 1 = 3
Ve skutečné práci je velmi obtížné uzavřít výsledek, když vydáme prohlášení jako -
- '... ..tato funkce je velmi obtížně implementovatelná'
Co myslíš tím obtížným? Je to složité, komplikované nebo chaotické?
Jak jste dospěl k závěru, že je to obtížné?
- '... toto by mělo být k dispozici do konce dne'
Co je konec dne? Váš konec dne je 19.00, pravděpodobně můj je 18.00?
- '... potřeboval bych to podrobně otestovat'
Co je to podrobné testování? Neexistuje žádná testovací technika zvaná „Podrobné testování“
zdarma ke stažení mp3 písničky aplikace pro Android
- '... kód by měl být kvalitní, než jej nasadíme do QA'
Jak měříte dobrou kvalitu?
Místo toho, pokud přeformuluji výroky jako -
Cyklomatická složitost pro část kódu se počítá jako 75 a podle našich standardů; tato funkce má povahu chaosu. Proto doporučujeme jej dále rozložit.
Přes
- '... ..tato funkce je velmi obtížně implementovatelná'
Funkce bude nasazena v prostředí QA do 17:00 CST.
Přes
- '… To by mělo být k dispozici do konce dne'
Vzhledem k tomu, že cyklomatická složitost se počítá jako 48, podle našeho standardu bychom prováděli testování systémů spolu s integračním a regresním testováním funkce.
Přes
- '… Potřeboval bych to podrobně otestovat'
Podle Sonaru je CC nyní 102. Standardizovali jsme CC tak, aby obsahovalo 10. Kód budeme nasazovat, až kód vylepšíme, aby byl CC méně než 10.
Přes
- '… Kód by měl být kvalitní, než jej nasadíme do QA'
Jaký je rozdíl mezi těmito dvěma tvrzeními?
Rozdíl je zde v měření. Každé své prohlášení jsem podpořil vhodným měřením, které by pomohlo mým zúčastněným stranám přesně vědět, co chci říct.
Podobně použijte Cyclomatic složitost v testování softwaru k určení přesné míry vašeho testovacího úsilí a můžete ji použít nejen k identifikaci rozsahu vašeho testování, ale také k typům testování, které byste museli udělat.
Doporučené čtení
- Co je Testování komponent nebo Testování modulů (Naučte se s příklady)
- Co je srovnávací testování (naučit se s příklady)
- Softwarový testovací kariérní balíček eBook
- Co je Testování integrace systému (SIT): Naučte se s příklady
- Nejlepší nástroje pro testování softwaru 2021 [QA Test Automation Tools]
- Testování stahování e-knih Primer
- 5 důležitých diagramů, které se testeři musí naučit používat
- Výukový program pro zkoušku TestRail: Naučte se komplexní správu testovacích případů