The document discusses various software testing techniques, including blackbox and whitebox testing. Blackbox testing focuses on functional requirements without seeing the internal structure and includes equivalence class testing, limit testing, robustness testing, and requirements testing. Whitebox testing uses internal program structure to derive test cases and focuses on all logical paths and decisions. It includes basis path testing and control structure testing such as conditional and loop testing. The document provides examples of applying these techniques.
4. 4
BLACK BOX
• Also known as behavioral testing or functional testing.
• Focus on the functional requirements of the software
• As a complement to white box testing (not as an alternative)
• Type :
• Equivalence Class Testing
• Limit Testing
• Robustness Testing
• Requirements Testing
5. 5
TESTING ASPECT
• Found errors in categories:
• Incorrect or missing functions
• Interface error
• Error in data structure or external database
access
• Performance error
• Initialization and termination error
6. 6
EQUIVALENCE CLASS TESTING
• Also known as Equivalence partitioning testing
• Black box testing that divides the input domain of
a program into data classes from which test cases
will be derived
• One test case covers one error class
• The data set of each data class has the same
effect on the program
• Reducing the number of test cases: efficiency
• An equivalence class represents an input
condition that represents a valid or invalid state
7. 7
LIMIT TESTING
• Also known as boundary value analysis
testing (BVA)
• Black box test that tests the
values contained in the limit (limit)
• General guideline - if an input condition is a
range between a and b then the test cases
(2 valid cases and 2 invalid cases)
8. 8
ROBUSTNESS TESTING
• Done by entering values that are outside the specified requirements
(requirements)
• Purpose : to prove that there are no garbled events (catastrophic :
hang, shutdown, etc.) in the software by inserting abnormal values
9. 9
REQUIREMENTS TESTING
• Black box testing is carried out to test
whether the specified requirements
(functional, performance, security, etc.)
during the needs analysis process are met or
not.
• Each requirement must be traceable to a test
case using a traceability matrix
15. 15
WHITE BOX
• A test case design method that uses a procedural design control
structure to obtain test cases.
• Also known as structural testing or glass box testing.
• Type :
• Basis path testing
• Control Structure Testing
16. 16
TESTING ASPECT
• Ensures that all independent paths in the
module have been executed at least once
• Carry out all logical decisions on the right and
wrong sides
• Execute all loops at their limits and within their
operational limits
• Conduct internal data structures to ensure their
validity
17. 17
TESTING FUNCTION
• Testing the software in terms of design and program code whether it
is able to produce functions, inputs and outputs that are in
accordance with the required specifications.
• White box testing examines the logic of the program code.
• The goal is to test all program statements (debug).
18. 18
BASIS PATH TESTING
• A white box test that was first proposed by Tom
McCabe.
• Allows testers to measure the logical complexity
of a procedural design and use it as a guide to
establish the basis set of all execution paths.
• It is used to measure the logical complexity of a
procedural design and use it as a guide to
establish the basis set of all execution paths.
• The test cases obtained are used to work on the
basis set which guarantees execution of each
command min 1x during the test.
19. 19
STEPS
• Define a flow graph based on the mapping
of the flow chart or the structure of the
algorithm
• Determine the size of the complexity
(cyclomatic complexity)
• Defining test cases
21. 21
FLOW GRAPH SYMBOL
• Circle (node) : describes one/more procedural
commands and which contains a condition marked
by two/more links derived from it (predicate). The
sequence of processes and decisions can be
mapped in a single node.
• The arrows (edges/links) : represent the flow of
control. Each node must have a destination node.
• Region : an area bounded by edges and nodes.
Including areas outside the flow chart.
• Predicate node : a node that is a condition (2 or
more edges will out from here)
22. 22
BASIS PATH TESTING NOTATION
The notation used to describe the path of execution is the flowchart
notation (or program graph), which uses the notation of circles (nodes)
and arrows (links or edges).
23. 23
CYCLOMATIC COMPLEXITY
• Number stating the number of independent paths
/base paths of a program (representation of
program complexity)
• Indicates the number of tests (test cases) to be
executed
• An independent path is a path that traverses or
through a program where it was executed at least
once. The independent path is equal to the sum
of its Cyclomatic Complexity.
24. 24
CALCULATION
• Cyclomatic Complexity can be obtained by
calculating the area that can be formed by the
graph (region)
• Cyclomatic Complexity V(G) can be calculated by
• V (G) = E – N + 2
• E = number of edges in flowgraph
• N = number of Nodes in the flowgraph
• Cyclomatic Complexity can also be calculated by
the formula:
• V (G) = P + 1
• P = number of Node predicates in flow graph
25. 25
Var
A, B, C : integer
Begin
1. A := 10;
2. B :=5;
3. C:= 6;
4. If A>B then
5. C:=A+B
6. Else if A>C then
7. C=A
8. Else C:=B;
9. Endif
10. Endif
11. Writeln(‘Nilai C = ‘,C);
12. End
V(G) = Jumlah Region
V(G) = 3
Atau
V(G) = E – N + 2
V (G) = 11 – 10 + 2 = 3
Atau
V (G) = P + 1
V (G) = 2 + 1 = 3
Jadi cyclomatic complexity
untuk flowgraph adalah 3
1,2,3
4
5 6
7 8
9
10
11
12
R1
R2
R3
29. 29
TEST CASE
• Test case path 1: 1-2-10-11-13
• Price (k) = valid input, where k < i which is set below
Price (i) = -999 where 2 ≤ 2i ≤ 100
• Expected result: correct average based on the value of k and total appropriate.
• Note: Path 1 cannot be tested alone because it must be tested as part of testing
Paths 4, 5 and 6
• Test case Path 2: 1-2-10-12-13
• Price (i) = -999
• Expected result : mean -999, other totals at baseline
• Test case path 3: 1-2-3-10-11-13
• Try to process 101 values or more.
• The first 100 values must be valid
• Expected results: the same as test case 1
30. 30
TEST CASE(CONT…)
• Test case path 4: 1-2-3-4-5-8-9-2- ....
• Value (i) = valid input where
i < 100 Value (k) < minimum, where k < i
• Expected result : true mean based on n values and correct total
• Test case path 5: 1-2-3-4-5-6-8-9-2-....
• Value (i) = valid input where
I < 100 Value (k) > maximum, where k ≤ i
• Expected result : correct mean based on n values and correct
total
• Test case path 6: 1-2-3-4-5-6-7-8-9-2-.........
• Value (i) = valid input where i < 100
• Expected result : correct mean based on n.i values and
correct total.
31. 31
EXPLANATION
• Each test case is executed and compared to get the
expected results.
• Once all the tests have been completed, the examiner
can be sure that all statements in the program have
been executed at least once.
• It is important to note that some independent paths
(eg path 1 in the example above) cannot be tested
separately because the data combinations required to
traverse those paths cannot be achieved in the normal
flow of the program.
• In such a case, paths are tested as part of another path
test.
32. 32
CONTROL STRUCTURE TESTING
• Control structure testing is done as a
complement to base path testing
• Type :
• Conditional Testing
• Loop Testing
33. 33
CONDITIONAL TESTING
• A white box test created to test logical
conditions in a program
• Types of conditions:
• Simple Conditional
• Compound Conditional
34. 34
LOOP TESTING
• White box testing is
performed to test the
validity of the loop structure
• Types of loops:
• Simple
• Nesting
• Concatenate
• Unstructured
35. 35
CLASS LEVEL TESTING
• Focuses on a single class and the
methods encapsulated by the class
• Test method:
• Random test
• Partition testing
36. 36
INTERCLASS TESTING
• Started at the time of system
integration OO
• Can be done by applying random and
partition methods, scenario-based and
behavioral testing
• Method :
• Multiple Class
• Behavior Model
37. References
Lewis, W. E. (2009). Software Testing And Continuous Quality
Improvement ed. 3rd. Auerbach publications.
02
Majchrzak, T. A. (2012). Improving Software Testing: Technical And
Organizational Developments. Springer Science & Business Media.
03
Myers, G. J., Sandler, C., & Badgett, T. (2012). The Art Of Software
Testing. John Wiley & Sons.
04
Roger, S. P., & Bruce, R. M. (2019). Software Engineering: A
Practitioner’s Approach Ed.9th. McGraw-Hill Education.
01