what is cyclomatic complexity learn with an example
La complexitat ciclomàtica és una paraula de moda molt comuna a la comunitat de desenvolupament. Aquesta tècnica s'utilitza principalment per determinar la complexitat d'un fragment de codi o funcionalitat.
La tècnica va ser desenvolupada per MaCabe i ajuda a identificar les 3 preguntes següents sobre els programes / funcions
- Es pot provar la funció / programa?
- Tothom entén la funció o el programa?
- La funció / programa és prou fiable?
Com a control de qualitat, podem utilitzar aquesta tècnica per identificar el 'nivell' de les nostres proves. És una pràctica que si el resultat de la complexitat ciclomàtica és més o més gran, considerem que aquesta peça de funcionalitat és de naturalesa complexa i, per tant, conclourem com a provador; que la part de codi / funcionalitat requereix proves en profunditat.
D'altra banda, si el resultat de la complexitat ciclomàtica és un nombre menor, conclouem com a QA que la funcionalitat és de menys complexitat i decidim l'abast en conseqüència.
Deixeu-me anar pas a pas: primer entenem com es calcula i, a continuació, continuarem entenent com es determina el nivell de proves.
Què aprendreu:
- Com es calcula la complexitat ciclomàtica?
- Fórmula de complexitat ciclomàtica
- Exemple de complexitat ciclomàtica
- Com els poden utilitzar els provadors?
- Ara arriba la drecera-
- Lectura recomanada
Com es calcula la complexitat ciclomàtica?
El càlcul de CC gira al voltant de 2 conceptes
- Nodes
- Vores
Les sentències d'un programa es representen com a nodes i els camins de control d'una sentència a una altra es representen mitjançant Edges.
Fórmula de complexitat ciclomàtica
La fórmula per calcular CC és la següent:
CC = E ~ N + 2
On:
E = Nombre d'arestes
N = Nombre de nodes.
(Hi ha una drecera per calcular-la, però no ara ... més tard ...)
Exemple de complexitat ciclomàtica
Prenguem l'exemple següent per entendre-ho.
Considereu el gràfic de flux de control següent:
He col·locat el XARXA punts per identificar els nodes i BLAU línies per identificar les vores:
Per tant, en aquest exemple:
Nombre de nodes (punts vermells) = 14
Nombre de vores (línies blaves) = 15
Per tant, la complexitat ciclomàtica = N ~ E + 2 = (14-15) +2 = 3
Com els poden utilitzar els provadors?
Al món real, els provadors poden estar amb els desenvolupadors per obtenir el gràfic de flux de control d'un tros de codi determinat. I un cop tenim el gràfic, podem obtenir la complexitat mitjançant aquesta fórmula. Però la història de Testers no acaba aquí: - el punt principal aquí és - Quina utilitat té aquest número per a l'equip de proves?
Bé, els verificadors poden fer servir aquest número per determinar el nivell de les proves.
A la pràctica hi ha dos nivells de proves:
- Proves de longitud
- Proves d'amplada
Tingueu en compte la següent matriu per a diferents funcions de qualsevol mòdul: -
La prova de longitud és una manera de provar de cobrir tot l'abast seleccionant els casos de prova importants per a cada funció. Per exemple , en aquest cas, suposo que selecciono implicar-ho amb la prova de longitud, i després puc seleccionar -
- Subfuncions 1.1 i Subfuncions 1.3 per a la funció 1
- Subfunció 2.2 de la funció 2
- Subfuncionalitat 3.3 de la funció 3
- Subfunció 4.2 i subfunció 4.3 de la funció 4
- Subfuncionalitat 5.3 de la funció 5
Així doncs, aquí estic tractant tota la funció sense entrar en detalls exhaustius de subfuncions.
Ara bé, si el resultat de la CC és un nombre més gran, trio escollir anar amb les proves de amplada, realment provaré totes i cadascuna de les funcions juntament amb totes i cadascuna de les subfuncions.
Així, segons els requisits del projecte actual, la fiabilitat del medi ambient, els verificadors poden col·laborar juntament amb l'equip de desenvolupament i crear un estàndard per identificar el nivell i l'abast de les proves. Per exemple -
- Si el CC<=15 – Basic sanity test
- Si el CC té entre 16 i 30 - Prova de longitud
- Si el CC té entre 31 i 50: proves de amplada
- Si el CC> 50: és una funcionalitat caòtica i necessita una descomposició addicional
Ara arriba la drecera-
Només cal comptar el nombre de regions tancades i afegir-hi 1.
En el nostre exemple anterior: nombre de regions tancades = 2 (omplert de groc), de manera que el CC = 2 + 1 = 3
A la feina real és molt difícil concloure el resultat quan fem afirmacions com:
- '... ... aquesta funcionalitat és molt difícil d'implementar'
Què vol dir amb dificultat? És complex, complicat o caòtic?
Com va arribar a la conclusió que això és difícil?
- '... hauria d'estar disponible al final del dia'
Què és el final del dia? El final del dia és a les 19:00, probablement el meu sigui a les 18:00?
- '... Hauria de fer proves detallades per a això'
Què són les proves detallades? No hi ha cap tècnica de prova anomenada 'Proves detallades'
- '... el codi ha de ser de bona qualitat abans de desplegar-lo a QA'
Com es mesura la bona qualitat?
quins són els diferents comptes de correu electrònic
En canvi, si reformulo les afirmacions com:
La complexitat ciclomàtica del fragment de codi es calcula com a 75 i segons els nostres estàndards; aquesta funcionalitat és de caos. Per tant, es recomana descomposar-lo encara més.
Acabat
- '... ... aquesta funcionalitat és molt difícil d'implementar'
La funcionalitat es desplegarà a l'entorn QA a les 17:00 CST.
Acabat
- '... hauria d'estar disponible al final del dia'
Com que la complexitat ciclomàtica es calcula com a 48, segons el nostre estàndard faríem les proves de sistemes juntament amb les proves d’integració i regressió de la característica.
Acabat
- '... Hauria de fer proves detallades per a això'
Segons Sonar, el CC ara és 102. Hem normalitzat per tenir el CC a 10. Estarem desplegant el codi quan millorem el codi per fer que el CC sigui inferior a 10.
Acabat
- '... El codi ha de ser de bona qualitat abans de desplegar-lo a QA'
Quina diferència hi ha entre les dues afirmacions?
Bé, la diferència aquí és la mesura. He donat suport a cadascuna de les meves declaracions amb la mesura adequada que ajudaria els meus grups d'interès a saber exactament el que vull dir.
De la mateixa manera, utilitzeu la complexitat ciclomàtica a les proves de programari per determinar la mesura exacta dels vostres esforços i podeu utilitzar-la per identificar no només l’abast de les proves, sinó també els tipus de proves que hauríeu de fer.
Lectura recomanada
- Què és la prova de components o la prova de mòduls (apreneu amb exemples)
- Què és la prova de comparació (apreneu amb exemples)
- Llibre electrònic de paquets de proves de programari
- Què és la prova d’integració de sistemes (SIT): apreneu amb exemples
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Prova de descàrrega de llibres electrònics
- 5 diagrames importants que els provadors han d’aprendre a utilitzar
- Tutorial de revisió de TestRail: aprengueu la gestió completa de casos de proves