This week, our class learned about path testing. It is a white box testing method (meaning we do not actually run the source code) that tests to make sure every specification is met and helps to create an outline for writing test cases. Each line of code is represented by a node and each progression point the compiler follows is represented by a directed edge. Test cases are written for each possible path the compiler can take.

For example, if we are testing the code block below, a path testing diagram can be created: also shown below. Each node represents a line of code and each directed edge represents where the compiler goes next, depending on the conditions. Test cases are written for each condition: running through the while loop and leaving when value is more than 5 or bypassing it if value starts as more than 5.

I wanted to learn more about path testing, so I did some research and found a blog that mentioned cyclomatic complexity. Cyclomatic complexity is a number that classifies how complex the code is based on how many nodes, edges, and conditionals you have. This number will relate to how many tests you need to run, but is not always the same number. The cyclomatic complexity of the example above would be (5-5)+2(1) = 2.

Cyclomatic Complexity = Edges – Nodes + 2(Number of Connected Components)

The blog also explores the advantages and disadvantages of path based testing. Some advantages are performing thorough testing of all paths, testing for errors in loops and branching points, and ensuring any potential bugs in pathing are found. Some disadvantages are failing to test input conditions or runtime compilations, a lot of tests need to be written to test every edge and path, and exponential growth in the number of test cases when code is more complex.

Another exercise we did in class was condensing nodes that do not branch. In the example above, node 2 and 3 can be condensed into one node. This is because there is no alternative path that can be taken between the nodes. If line 2 is run, line 3 is always run right after, no matter what number value is. Condensing nodes would be helpful in slightly more complex programs to make the diagram more readable. Though if you are working with a program with a couple hundred lines, this seems negligible.

When I am writing tests for a program in the future, I would probably choose a more time conscious method. Cyclomatic complexity is a good and useful metric to have, but basing test cases off of the path testing diagram does not seem practical for complex codes and tight time constraints.

Blog post referenced: https://www.testbytes.net/blog/path-coverage-testing/

From the blog CS@Worcester – ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

This week we learned about boundary value testing and equivalence class testing. Boundary value testing focuses on making sure the values in, out, and around the expected boundary works as it should. Equivalence class testing does the same, but also tests the function itself.

I wanted to know more about the two methods and found a blog post that explains them a little more in depth. The author, Apoorva Ram, says they are more thought processes than testing methods really. The thought process of boundary value testing is self explanatory: testing the edge boundaries of the function. The thought process of equivalence class testing is organizing every possible input into groups of expected outputs and testing the result from each.

Ram also explains the benefits of the methods and how they can be used in software testing. The two seem to go hand in hand. Planning your tests before writing them and knowing the expected output makes the testing process a lot smoother. You know what points you need to hit and have a plan to execute them. Additionally, knowing all the points you need to hit allows you to prioritize ones that are more important.

For example, say you have a boolean function that looks for the input value to be between 15 and 30, but accepts values from 0 to 100. Boundary testing would test the values of xmin-, xmin, xmin+, xnom, xmax-, xmax, and xmax+. In this case: -1, 0, 1, 50, 99, 100, and 101. It mostly makes sure the 0 and 100 boundaries work. But equivalence class testing breaks down the function into classes of values that will give every result: invalid inputs (under 0 and above 100), false cases (between 0-14 and between 31-100), and the true case (between 15-30). In this case: -1, 12, 20, 45, and 101. This method tests the valid ranges as well as the function ranges.

In my opinion, equivalence class testing is better than boundary value testing because it actually tests the function and not just the illegal argument exception, and it eliminates redundant tests like xmin+, xnom, and xmax-, all testing for the same output without actually testing the function. Though ideally, a mix of both would probably be the method I choose. For this example, I would test each equivalence class and its boundaries: xmin-, xmin, xmin+, xtruemin-, xtruemin, xtruemin+, xtruemax-, xtruemax, xtruemax+, xmax-, xmax, and xmax+ (-1, 0, 1, 14, 15, 16, 29, 30, 31, 99, 100, 101).

Blog post referenced: https://testsigma.com/blog/boundary-value-analysis-and-equivalence-class-partitioning/

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.