Equivalence partitioning is a black-box testing method that divides the input domain of
a program into classes of data from which test cases can be derived. An ideal test case
single-handedly uncovers a class of errors (e.g., incorrect processing of all character
data) that might otherwise require many cases to be executed before the general error
is observed. Equivalence partitioning strives to define a test case that uncovers classes
of errors, thereby reducing the total number of test cases that must be developed.
An equivalence class represents
a set of valid or invalid states for input conditions. Typically, an input condition
is either a specific numeric value, a range of values, a set of related values, or a Boolean
condition.
Equivalence partitioning is a software testing technique that divides the input data of a software unit into partition of data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once.
Partitioning is done such that:
program behaves in similar ways to every input value belonging to an equivalence class.
flow graph node, represents one or more
procedural statements.
The arrows on the flow graph, called edges or links
How to draw control flow graph
Number all the statements of a program.
Numbered statements:
represent nodes of the control flow graph.
An edge from one node to another node exists:
if execution of the statement representing the first node can result in transfer of control to the other node.
Selects test paths of a program:
according to the locations of definitions and uses of different variables in a program.
Variation of the control flow graph
A node represents a single statement, not a
single-entry-single-exit chain of statements
Black-box testing, also called behavioral testing, focuses on the functional requirements
of the software. That is, black-box testing enables the software engineer to
derive sets of input conditions that will fully exercise all functional requirements for
a program. Black-box testing is not an alternative to white-box techniques. Rather,
it is a complementary approach that is likely to uncover a different class of errors
than white-box methods.
Black-box testing attempts to find errors in the following categories: (1) incorrect
or missing functions, (2) interface errors, (3) errors in data structures or external data
base access, (4) behavior or performance errors, and (5) initialization and termination
errors.
Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also called as "Opaque Testing", "Functional/Behavioral Testing" and "Closed Box Testing".
Checks Actual results are according top specified behaviour or not.
The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. An input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition.
greater number of errors tends to occur
at the boundaries of the input domain rather than in the "center." It is for this reason
that boundary value analysis (BVA) has been developed as a testing technique
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
Programmers may improperly use < instead of <=
Boundary value analysis:
select test cases at the boundaries of different equivalence classes.
greater number of errors tends to occur
at the boundaries of the input domain rather than in the "center." It is for this reason
that boundary value analysis (BVA) has been developed as a testing technique
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
Programmers may improperly use < instead of <=
Boundary value analysis:
select test cases at the boundaries of different equivalence classes.
greater number of errors tends to occur
at the boundaries of the input domain rather than in the "center." It is for this reason
that boundary value analysis (BVA) has been developed as a testing technique
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
Programmers may improperly use < instead of <=
Boundary value analysis:
select test cases at the boundaries of different equivalence classes.
greater number of errors tends to occur
at the boundaries of the input domain rather than in the "center." It is for this reason
that boundary value analysis (BVA) has been developed as a testing technique
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
Programmers may improperly use < instead of <=
Boundary value analysis:
select test cases at the boundaries of different equivalence classes.
greater number of errors tends to occur
at the boundaries of the input domain rather than in the "center." It is for this reason
that boundary value analysis (BVA) has been developed as a testing technique
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
Programmers may improperly use < instead of <=
Boundary value analysis:
select test cases at the boundaries of different equivalence classes.
This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.
Using white-box testing methods, the software engineer can derive test cases that (1) guarantee
that all independent paths within a module have been exercised at least once,
(2) exercise all logical decisions on their true and false sides, (3) execute all loops at
their boundaries and within their operational bounds, and (4) exercise internal data
structures to ensure their validity.
White-box testing, sometimes called glass-box testing, is a test case design method
that uses the control structure of the procedural design to derive test cases. Using
A reasonable question might be posed at this juncture: "Why spend time and energy
worrying about (and testing) logical minutiae when we might better expend effort
White box testing (a.k.a. clear box testing, glass box testing, transparent box testing, translucent box testing or structural testing) uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software.
While white box testing is applicable at the unit, integration and system levels of the software testing process, it is typically applied to the unit.
it might not detect unimplemented parts of the specification or missing requirements, but one can be sure that all paths through the test object are executed.
Statement coverage methodology:
design test cases so that every statement in a program is executed at least once.
The principal idea:
unless a statement is executed, we have no way of knowing if an error exists in that statement
Suppose that we write and
execute two test cases
Test case #1: follows path 1-2-exit
Test case #2: 1-2-3-4-5-7-8-2-3-4-5-7-8-2-exit
(loop twice, and both times
take the true branch)
Problem: node 6 is never
executed,so we don’t have 100% statement coverage
ranch coverage (sometimes called Decision Coverage) measures which possible branches in flow control structures are followed
Branch testing guarantees statement coverage:
a stronger testing compared to the statement coverage-based testing.
A branch is the outcome of a decision, so branch coverage simply measures which decision outcomes have been tested. This sounds great because it takes a more in-depth view of the source code than simple statement coverage, but branch coverage can also leave you wanting more.
Determining the number of branches in a method is easy. Boolean decisions obviously have two outcomes, true and false, whereas switches have one outcome for each case—and don't forget the default case! The total number of decision outcomes in a method is therefore equal to the number of branches that need to be covered plus the entry branch in the method (after all, even methods with straight line code have one branch).
In the example above, returnInput() has seven branches—three true, three false, and one invisible branch for the method entry. You can cover the six true and false branches with two test cases:
Suppose that we write and
execute two test cases
Test case #1: follows path 1-2-exit
Test case #2: 1-2-3-4-5-7-8-2-3-4-5-7-8-2-exit
(loop twice, and both times
take the true branch)
Problem: node 6 is never
executed,so we don’t have 100% statement coverage
Condition testing is a test case design method that exercises the logical conditions
contained in a program module. A simple condition is a Boolean variable or a relational
expression, possibly preceded with one NOT (¬) operator.
A path is a unique sequence of branches from the function entry to the exit.Path coverage has the advantage of requiring very thorough testing. Path coverage has two severe disadvantages. The first is that the number of paths is exponential to the number of branches. For example a function containing 10 if-statements has 1024 paths to test. Adding just one more if-statement doubles the count to 2048. The second disadvantage is that many paths are impossible to exercise due to relationships of data. For example consider the following C/C++ code fragment:if (success) statement1;statement2;if (success) statement3;Path coverage considers this fragment to contain 4 paths. In fact only two are feasible: success false and success true.
A path represents the flow of execution from the start of a method to its exit. A method with N decisions has 2^N possible paths, and if the method contains a loop, it may have an infinite number of paths. Fortunately, you can use a metric called cyclomatic complexity to reduce the number of paths you need to test.
The cyclomatic complexity of a method is one plus the number of unique decisions in the method. Cyclomatic complexity helps you define the number of linearly independent paths, called the basis set, through a method. The definition of linear independence is beyond the scope of this article, but, in summary, the basis set is the smallest set of paths that can be combined to create every other possible path through a method.
Like branch coverage, testing the basis set of paths ensures that you test every decision outcome, but, unlike branch coverage, basis path coverage ensures that you test all decision outcomes independently of one another. In other words, each new basis path "flips" exactly one previously executed decision, leaving all other executed branches unchanged. This is the crucial factor that makes basis path coverage more robust than branch coverage, and allows you to see how changing that one decision affects the method's behavior.
A path is a unique sequence of branches from the function entry to the exit.Path coverage has the advantage of requiring very thorough testing. Path coverage has two severe disadvantages. The first is that the number of paths is exponential to the number of branches. For example a function containing 10 if-statements has 1024 paths to test. Adding just one more if-statement doubles the count to 2048. The second disadvantage is that many paths are impossible to exercise due to relationships of data. For example consider the following C/C++ code fragment:if (success) statement1;statement2;if (success) statement3;Path coverage considers this fragment to contain 4 paths. In fact only two are feasible: success false and success true.
A path represents the flow of execution from the start of a method to its exit. A method with N decisions has 2^N possible paths, and if the method contains a loop, it may have an infinite number of paths. Fortunately, you can use a metric called cyclomatic complexity to reduce the number of paths you need to test.
The cyclomatic complexity of a method is one plus the number of unique decisions in the method. Cyclomatic complexity helps you define the number of linearly independent paths, called the basis set, through a method. The definition of linear independence is beyond the scope of this article, but, in summary, the basis set is the smallest set of paths that can be combined to create every other possible path through a method.
Like branch coverage, testing the basis set of paths ensures that you test every decision outcome, but, unlike branch coverage, basis path coverage ensures that you test all decision outcomes independently of one another. In other words, each new basis path "flips" exactly one previously executed decision, leaving all other executed branches unchanged. This is the crucial factor that makes basis path coverage more robust than branch coverage, and allows you to see how changing that one decision affects the method's behavior.
A path is a unique sequence of branches from the function entry to the exit.Path coverage has the advantage of requiring very thorough testing. Path coverage has two severe disadvantages. The first is that the number of paths is exponential to the number of branches. For example a function containing 10 if-statements has 1024 paths to test. Adding just one more if-statement doubles the count to 2048. The second disadvantage is that many paths are impossible to exercise due to relationships of data. For example consider the following C/C++ code fragment:if (success) statement1;statement2;if (success) statement3;Path coverage considers this fragment to contain 4 paths. In fact only two are feasible: success false and success true.
A path represents the flow of execution from the start of a method to its exit. A method with N decisions has 2^N possible paths, and if the method contains a loop, it may have an infinite number of paths. Fortunately, you can use a metric called cyclomatic complexity to reduce the number of paths you need to test.
The cyclomatic complexity of a method is one plus the number of unique decisions in the method. Cyclomatic complexity helps you define the number of linearly independent paths, called the basis set, through a method. The definition of linear independence is beyond the scope of this article, but, in summary, the basis set is the smallest set of paths that can be combined to create every other possible path through a method.
Like branch coverage, testing the basis set of paths ensures that you test every decision outcome, but, unlike branch coverage, basis path coverage ensures that you test all decision outcomes independently of one another. In other words, each new basis path "flips" exactly one previously executed decision, leaving all other executed branches unchanged. This is the crucial factor that makes basis path coverage more robust than branch coverage, and allows you to see how changing that one decision affects the method's behavior.
greater number of errors tends to occur
at the boundaries of the input domain rather than in the "center." It is for this reason
that boundary value analysis (BVA) has been developed as a testing technique
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
Programmers may improperly use < instead of <=
Boundary value analysis:
select test cases at the boundaries of different equivalence classes.
