To understand Cyclomatic Complexity, lets first understand - What is Software Metric? Measurement is nothing but quantitative indication of size / dimension / capacity of an attribute of a product / process.
Software metric is defined as a quantitative measure of an attribute a software system possesses with respect to Cost, Quality, Size and Schedule. Example- Measure - No. Of Errors Metrics - No. Of Errors found per person What is Cyclomatic Complexity?
.png "Cyclomatic")
Cyclomatic complexity is a software metric used to measure the complexity of a program. These metric, measures independent paths through program source code. Independent path is defined as a path that has at least one edge which has not been traversed before in any other paths. Cyclomatic complexity can be calculated with respect to functions, modules, methods or classes within a program. This metric was developed by Thomas J. McCabe in 1976 and it is based on a control flow representation of the program. Control flow depicts a program as a graph which consists of Nodes and Edges.
In the graph, Nodes represent processing tasks while edges represent control flow between the nodes. Flow graph notation for a program: Flow Graph notation for a program is defines. Several nodes connected through the edges.
Below are Flow diagrams for statements like if-else, While, until and normal sequence of flow. Mathematical representation. Mathematically, it is set of independent paths through the graph diagram. The complexity of the program can be defined as - V(G) = E - N + 2 Where, E - Number of edges N - Number of Nodes V (G) = P + 1 Where P = Number of predicate nodes (node that contains condition) Example - i = 0; n=4; //N-Number of nodes present in the graph while (i=1. G will have one path if V (G) = 1. Minimize complexity to 10 How this metric is useful for software testing?
Basis Path testing is one of White box technique and it guarantees to execute atleast one statement during testing. It checks each linearly independent path through the program, which means number test cases, will be equivalent to the cyclomatic complexity of the program. This metric is useful because of properties of Cyclomatic complexity (M) -. M can be number of test cases to achieve branch coverage (Upper Bound). M can be number of paths through the graphs. (Lower Bound) Consider this example - If (Condition 1) Statement 1 Else Statement 2 If (Condition 2) Statement 3 Else Statement 4 Cyclomatic Complexity for this program will be 9-7+2=4. As complexity has calculated as 4, four test cases are necessary to the complete path coverage for the above example.
Steps to be followed: The following steps should be followed for computing Cyclomatic complexity and test cases design. Step 1 - Construction of graph with nodes and edges from the code Step 2 - Identification of independent paths Step 3 - Cyclomatic Complexity Calculation Step 4 - Design of Test Cases Once the basic set is formed, TEST CASES should be written to execute all the paths. More on V (G): Cyclomatic complexity can be calculated manually if the program is small. Automated tools need to be used if the program is very complex as this involves more flow graphs. Based on complexity number, team can conclude on the actions that need to be taken for measure.
Following table gives overview on the complexity number and corresponding meaning of v (G): Complexity Number Meaning 1-10 Structured and well written code High Testability Cost and Effort is less 10-20 Complex Code Medium Testability Cost and effort is Medium 20-40 Very complex Code Low Testability Cost and Effort are high 40 Not at all testable Very high Cost and Effort Tools for Cyclomatic Complexity calculation: Many tools are available for determining the complexity of the application. Some complexity calculation tools are used for specific technologies. Complexity can be found by the number of decision points in a program.
The decision points are if, for, for-each, while, do, catch, case statements in a source code.
Manual Cyclomatic App
Cyclomatic Complexity is a very common buzz word in the Development community. This technique is mainly used to determine the complexity of a piece of code or functionality. The technique was developed by MaCabe and helps to identify the below 3 questions for the programs / features. Is the feature / program testable?. Is the feature/ program understood by every one?. Is the feature / program reliable enough? As a QA we can use this technique to identify the “level” of our testing.
It is a practice that if the result of cyclomatic complexity is more or a bigger number, we consider that piece of functionality to be of complex nature and hence we conclude as a tester; that the piece of code / functionality requires an in-depth testing. On the other hand if the result of the Cyclomatic Complexity is a smaller number, we conclude as QA that the functionality is of less complexity and decide the scope accordingly. What You Will Learn:.
How to Calculate Cyclomatic Complexity? The calculation of CC revolves around 2 concepts. Nodes.
Edges Statements in a program are represented as nodes, and control paths from one statement to another are represented by Edges. Cyclomatic Complexity formula The formula for calculating CC is as: CC = EN+2 Where: E= Number of edges N= Number of nodes. (There is a shortcut for calculating it, but not nowlater) Cyclomatic Complexity Example Lets take the below example to understand it. Consider the below Control flow graph: I have placed the REDdots to identify the Nodes and BLUElines to identify the edges: So here in this example: Number of Nodes (Red dots) = 14 Number of Edges (Blue Lines) = 15 So the Cyclomatic Complexity = NE+2 = (14-15) +2 = 3 How can Testers use it?
In real world, Testers can sit with developers to derive the control flow graph for a given piece of code. And once we have the graph, we can derive the complexity using this formula. But the story for Testers does not end here: – the main point here is – what is the use of this number for the testing team? Well, Testers can make use of this number to determine the level of their testing.
In practice there are 2 levels of testing:-. Length Testing. Breadth Testing Consider the below matrix for different features of any module.
Length Testing is a way by which we try to cover the entire scope by selecting the important test cases for each feature. For example in this case suppose I select to imply with the Length testing, then I may select –. Sub feature 1.1 and Sub Feature 1.3 for Feature 1.
Sub feature 2.2 from Feature 2. Sub Feature 3.3 from Feature 3. Sub Feature 4.2 and Sub Feature 4.3from Feature 4. Sub Feature 5.3 from Feature 5 So here I am touching upon the entire feature without going into exhaustive details of sub features. Now if the result of the CC is a bigger number then I choose to go with Breadth testing, I will be actually testing each and every feature along with each and every sub feature.
So based on your current project requirement, environment dependability, testers can collaborate together with the development team and create a standard for identification of the level and scope of testing. For example –. If the CC 50 – It’s a chaotic functionality and needs further decomposition Now comes the shortcut- Just count the number of closed region and add 1 to it. In our example above – number of closed region = 2(filled in yellow), so the CC = 2+1 = 3 In the real work it’s very difficult to conclude the result when we give statements like –. “.this functionality is very difficult to implement” What do you mean by difficult? Is it complex, complicated or chaotic? How did you conclude that this is difficult?.
“this should be available by end of day” What is end of the day? Your end of the day is 7.00 pm, probably mine is 6.00 pm?. “I would need to do detailed testing for this” What is detailed testing?
There is no testing technique called “Detailed Testing”. “the code should be of good quality before we deploy it to QA” How do you measure good quality? Instead, If I rephrase the statements like – The Cyclomatic Complexity for the piece of code is calculated as 75 and as per our standards; this functionality is of Chaos nature. Hence we recommend further decomposing it.
Over. “.this functionality is very difficult to implement” The functionality will be deployed in QA environment by 5.00 PM CST. Over. “.this should be available by end of day” Since the Cyclomatic complexity is calculated as 48, as per our standard we would be doing the systems testing along with the Integration and Regression testing for the feature. Over.
“.I would need to do detailed testing for this” As per Sonar, the CC is now 102. We have standardized to have the CC to 10. We will be deploying the code when we improve the code to make the CC less than 10. Over. “.the code should be of good quality before we deploy it to QA” What is the difference in the two statements? Well, the difference here is measurement. I have supported each of my statement with appropriate measurement which would help my stakeholders to know exactly what I want to say.
Similarly use Cyclomatic complexity in software testing to determine the exact measure of your testing efforts and you can use it to not only identify scope of your testing but also the types of testing which you would need to do.