CPSC 463 Final

Normal Boundary Value Testing

Checking values right at their boundary limits.

Ex: If range is 1-100, we check 1, 2, 99, 100

Robust Normal Boundary Value Testing

Check values right at the limit and just outside the limit

Ex: Range is from 5-20, we check 5, 6, 19, 20 and 4, 21

Worst Case Boundary Testing

Given a sitaution where you have multiple variables that work together, you will test boundary values for combinations.

Robust worst case boundary value testing

Builds on WCBT and tests values outside of the acceptable range

Single Fault Assumption

A fault when it occurs can be traced back to things associated with a single input variable (x or y)

Single-Fault Normal Equivalence class testing

Running one test case per partition on a graph. If we have 5 partitions there will be on test case in each one, but we must also ensure that theres one per x partition

Strong Normal Equivalence Testing

Place a test in every partition combination to cover all possibilities

What does specification mean

Formal description of how a system or component is supposed to behave

What does class mean in equivalence class testing

A set of values

Program Graph

Each line of code receives a node. You begin connecting based off the flow of the code. Ex: An if statement can either be true, so continue forward, or false so jump to the node that would follow if false

Segment Graph

Take a program graph and abstract it as much as possible. All lines will be written down, but nodes will be combined. Ex: if you have three assignment nodes on a row, combine all three into 1, and then write next to it =, =, = to show that theres 3.

Decision Graph

Abstract segment graph once more, and only create a node for decision statements. Ex: In, while, if, out. they are connected by e_x

Is 100% program coverage good enough to catch all bugs?

No, this only checks that every line runs at least once. it does not ensure that all conditions are tested both true and false

Is 100% branch coverage good enough to catch all bugs?

No, this ensures each decision outcome runs, but does not guarantee and condition combinatiosn are tested

Is 100% path coverage good enough to catch all bugs?

Yes

Statement Coverage

If your test cases collectively traverse all nodes of the program graph, you can say that your
test cases produce 100%

Branch Coverage

If your test cases collectively traverse all edges of the decision graph, you can say that your
test cases produce 100%

Basis path coverage

A measure of testing all independent paths through a progam

Define/Use testing

Divide and conquer approach to simplify testing. You take a chunk of code and identify the Define variables. Ex input(price) on line 5 and 8 of the textbook. The use is how those Defines are used. so lines 6, 7, 8. You then write out all the possible paths the Define can take.

Slice based testing

Divide an conquer technique to focus on smaller sections of code. Lets say we have 10 lines of code and we only want to focus on the variable product. Remove every line that has 0 effect on product and focus only on the lines that do

Program Dependence Graph

Nodes are statements and edges represent either control dependence or data dependence

control Dependence graph

Start with a entry box and that connects to every node that can be reached from the start. And then from those nodes connect to following nodes

Flow Dependence graph

Connect nodes that share a relationship. This follows a different flow in the sens that youre not going based off whats the next code line. If the current node is sum = 0, connect that to every following sum node. Ex: sum = 0 → sum = sum+ 1 or output(sum)

Program dependence

Connect nodes based off where they progress next based off line order, and then connect to other nodes they directly affect

Backward Slice

Graph based on the criterion you select. In the example we want to test variable i so we end up with every node that directly affects i.