materi tis10
TRANSCRIPT
-
7/29/2019 Materi TIS10
1/53
Testing dan
Implementasi Sistem
Siti Muharramah
-
7/29/2019 Materi TIS10
2/53
Objektivitas
Pemahaman mengenai use case
-
7/29/2019 Materi TIS10
3/53
3
Importance of Testing inSDLC & Various Kinds of
Testing
-
7/29/2019 Materi TIS10
4/53
4
Software Development LifecycleAll software development can be characterized as a problem solving loop in which
four distinct stages are encounter: -
Status quo: represents the current state of affairs;
Problem definition: identifies the specific problem to be solved
Technical development: solves the problem through the application of some
technology.
Solution integration: delivers the results (e.g., documents, programs, data, new
business function, new product) to those who requested the solution in the first
Place.
-
7/29/2019 Materi TIS10
5/53
5
Waterfall Model
Analysis Design Code Test
System/informationengineering
-
7/29/2019 Materi TIS10
6/53
6
The Prototyping ModelListen tocustomer Build/revise mock-up
Customertest-drivesmock-up
-
7/29/2019 Materi TIS10
7/53
7
The RAD ModelBusinessmodeling
Datamodeling
Processmodelin
g
Application modeling
Testand
turnover
Businessmodeling
Datamodeling
Processmodeling
Applicationmodeling
Test andturnover
Businessmodeling
Datamodeling
Processmodelin
g
Application modeling
Testand
turnover
Team #1
Team #2
Team #3
-
7/29/2019 Materi TIS10
8/53
8
Boehms Spiral Model
-
7/29/2019 Materi TIS10
9/53
9
V- Model
SRS
Unit test
Testedmodules
Integration Test
Integratedsoftware
System
Integration Test
Testedsoftware
System Test,
AcceptanceTest
Requirements
Specification
System Design
Detailed
Design
Coding
SystemDesign
SRS
Moduledesigns
Code
UserManual
-
7/29/2019 Materi TIS10
10/53
10
Importance of Software testing in SDLC Its helps to verify that all the software requirements are implemented
correctly or not.
Identifying defects and ensuring they are addressed before software
deployment. Because if any defect will found after deployment and force
to fixed it, than the correction cost will much higher than the cost of it
fixed it at earlier stage of development.
Effective testing is demonstrates that software-testing function appear to
be working according to specification, that behavioral and performance
requirement appear to have been met.
Whenever any system is developed in different components, its helps to
verify the proper integration/interaction of each component to rest of the
system.
Data collection as testing is conducted provide a good indication of
software reliability and some indication of software quality as a whole.
-
7/29/2019 Materi TIS10
11/53
11
Different Types of Testing Dynamic v/s static testing.
Development v/s independent testing.
Black v/s white box testing.
Behavioral v/s structural testing.
Automated v/s manual testing.
Sanity, acceptance and smoke testing .
Regression testing.
Exploratory and monkey testing.
Debugging v/s be bugging.
-
7/29/2019 Materi TIS10
12/53
12
Dynamic v/s staticStatic Testing: This testing refers to testing something thats not
running-Examining and reviewing it.
Dynamic Testing: This you would normally think of as testing-
running and using the software.
-
7/29/2019 Materi TIS10
13/53
13
Development v/s independent testingDevelopment testing denotes the aspects of test design and implementation
most appropriate for the team of developers to undertake. This is in contrastto Independent Testing. In most cases, test execution initially occurs with
the developer testing group who designed and implemented the test, but it is
a good practice for the developers to create their tests in such a way so as to
make them available to independent testing groups for execution.
Independent testing denotes the test design and implementation most
appropriately performed by someone who is independent from the team of
developers. You can consider this distinction a superset, which includes
Independent Verification & Validation. In most cases, test execution initially
occurs with the independent testing group that designed and implemented
the test, but the independent testers should create their tests to make them
available to the developer testing groups for execution
-
7/29/2019 Materi TIS10
14/53
14
Black v/s white box testingThe purpose of a black-box test is to verify the unit's specified function and
observable behavior without knowledge ofhow the unit implements the
function and behavior. Black-box tests focus and rely upon the unit's input
and output.
A white-box test approach should be taken to verify a unit's internal
structure. Theoretically, you should test every possible path through the
code, but that is possible only in very simple units. At the very least you
should exercise every decision-to-decision path (DD-path) at least once
because you are then executing all statements at least once. A decision is
typically an if-statement, and a DD-path is a path between two decisions.
-
7/29/2019 Materi TIS10
15/53
15
Behavioral v/s structural testing
Behavioral Testing:This is another name commonly given to Black Box
Testing as you are testing the behavior of the software when its used
without knowing the internal logics how they are implemented.
Structural Testing:This is another name commonly used for white Box
testing in which you can see and use the underlying structure of the code to
design and run your tests.
-
7/29/2019 Materi TIS10
16/53
16
Automated v/s manualAutomated Testing: Software testing assisted with software tools that
require no operator input, analysis, or evaluation.
Manual Testing: That part of software testing that requires human input,
analysis, or evaluation.
-
7/29/2019 Materi TIS10
17/53
17
Sanity, Acceptance and Smoke testingSanity Testing: Sanity testing is a cursory testing; it is performed whenever a
cursory testing is sufficient to prove the application is functioning accordingto specifications. It normally includes a set of core tests of basic GUI
functionality to demonstrate connectivity to the database, application
servers, printers, etc.
Acceptance testing: Acceptance testing is the final test action before deploying
the software. The goal of acceptance testing is to verify that the software is
ready and can be used by your end users to perform those functions and
tasks for which the software was built.
Smoke Testing: Smoke testing is non-exhaustive software testing, ascertaining
that the most crucial functions of a program work, but not bothering with
finer details.
-
7/29/2019 Materi TIS10
18/53
18
Regression testingThe selective retesting of a software system that has been modified to
ensure that any bugs have been fixed and that no other previously
working functions have failed as a result of the modifications and that
newly added features have not created problems with previous versions
of the software.
Regression testing is initiated after a programmer has attempted to fix a
recognized problem or has added source code to a program that may
have inadvertently introduced errors. It is a quality control measure to
ensure that the newly modified code still complies with its specified
requirements and that unmodified code has not been affected by the
maintenance activity.
-
7/29/2019 Materi TIS10
19/53
19
Exploratory and monkey testingExploratory testing involves simultaneously learning,
planning, running tests, and reporting /troubleshooting results.
Monkey testing- This is another name for "Ad HocTesting"; it comes from the joke that if you put 100monkeys in a room with 100 typewriters, randomlypunching keys, sooner or later they will type out a
Shakespearean sonnet. So every time one of your adhoc testers finds a new bug, you can toss him abanana. The use of monkey testing is to simulate howyour customers will use your software in real time.
-
7/29/2019 Materi TIS10
20/53
20
Debugging v/s bebuggingDebugging: The process of finding and removing the causes of
failures in software. The role is performed by a programmer.
Bebugging:The process of intentionally adding known faults to those
already in a computer program for the purpose of monitoring the
rate of detection and removal, and estimating the number of faults
remaining in the program
-
7/29/2019 Materi TIS10
21/53
21
Black Box & White BoxTesting Techniques
-
7/29/2019 Materi TIS10
22/53
22
Black-Box TestingProgram viewed as a Black-box, which accepts some inputsand produces some outputs
Test cases are derived solely from the specifications,
without knowledge of the internal structure of theprogram.
-
7/29/2019 Materi TIS10
23/53
23
Functional Test-Case Design Techniques
Equivalence class partitioning
Boundary value analysis
Cause-effect graphing
Error guessing
-
7/29/2019 Materi TIS10
24/53
24
Equivalence Class PartitioningPartition the program input domain into equivalence classes(classes of data which according to the specifications aretreated identically by the program)
The basis of this technique is that test of a representativevalue of each class is equivalent to a test of any other valueof the same class.
Identify valid as well as invalid equivalence classes
For each equivalence class, generate a test case to exercisean input representative of that class
-
7/29/2019 Materi TIS10
25/53
25
ExampleExample: input condition 0
-
7/29/2019 Materi TIS10
26/53
26
Guidelines for Identifying Equivalence ClassesInput Condition Valid Eq Classes Invalid Eq Classes
range of values one valid two inavlid
(eg. 1 - 200) (value within range) (one outside eachend of range)
number N valid one valid two invalid
values (none, more than N)
Set of input values one valid eq class one
each handled for each value (eg. any value not
differently by the in valid input set )
program (eg. A, B, C)
-
7/29/2019 Materi TIS10
27/53
27
Guidelines for Identifying Equivalence ClassesInput Condition Valid Eq Classes Invalid Eq Classes
must be condition one one
(e.g. Id name must begin (e.g.. it is a letter) (e.g.. it is not a letter)with a letter )
If you know that elements in an equivalence class are not handledidentically by the program, split the equivalence class into smallerequivalence classes.
-
7/29/2019 Materi TIS10
28/53
28
Identifying Test Cases for Equivalence ClassesAssign a unique number to each equivalence class
Until all valid equivalence classes have been covered bytest cases, write a new test case covering as many of theuncovered valid equivalence classes as possible.
Each invalid equivalence class cover by a separate testcase.
-
7/29/2019 Materi TIS10
29/53
29
Boundary Value AnalysisDesign test cases that exercise values that lie at the
boundaries of an equivalence class and for situations justbeyond the ends.
Example: input condition 0
-
7/29/2019 Materi TIS10
30/53
30
Cause Effect GraphingA technique that aids in selecting test cases for combinationsof input conditions in a systematic way.
-
7/29/2019 Materi TIS10
31/53
31
Cause Effect Graphing Technique1. Identify the causes (input conditions) and effects (output
conditions) of the program under test.
2. For each effect, identify the causes that can produce thateffect. Draw a Cause-Effect Graph.
3. Generate a test case for each combination of input conditionsthat make some effect to be true.
-
7/29/2019 Materi TIS10
32/53
32
ExampleConsider a program with the following:
Input conditions Output conditions
c1: command is credit e1: print invalid command
c2: command is debit e2: print invalid A/C
c3: A/C is valid e3: print debit amountnot valid
c4: Transaction amount not e4: debit A/Cvalid e5: credit A/C
-
7/29/2019 Materi TIS10
33/53
33
Example: Cause-Effect Graph
C1
C2
C3
C4
E1
E2
E3
E5
E4andand
or
and
and
and
and
and
not
not
-
7/29/2019 Materi TIS10
34/53
34
and
Example: Cause-Effect GraphC1
C2
C3
C4
E1
E2
E5
E4
E3and and
ornot
andand
andand
not
-
7/29/2019 Materi TIS10
35/53
35
ExampleDecision table showing the combinations of input
conditions that make an effect true. (Summarized fromCause Effect Graph)
Write test cases to exercise each Rule in decision Table.
Example: C1C2
C3
C4
00
-
-
1-
0
-
-1
1
0
-1
1
1
1-
1
1
E1
E2
E3
E4
E5
1
1
1
1
1
-
7/29/2019 Materi TIS10
36/53
36
Error GuessingFrom intuition and experience, enumerate a list of possible
errors or error prone situations and then write test cases toexpose those errors.
-
7/29/2019 Materi TIS10
37/53
37
White Box TestingWhite box testing is concerned with the degree to which testcases exercise or cover the logic (source code) of the program.
White box Test case design techniques
Statement coverage Basis Path Testing
Decision coverage Loop testing
Condition coverage Decision-condition coverage
Multiple condition coverage Data flow testing
-
7/29/2019 Materi TIS10
38/53
38
White Box Test-Case DesignStatement coverage write enough test cases to execute every statement atleast once
TER (Test Effectiveness Ratio)
TER1 = statements exercised / total statements
-
7/29/2019 Materi TIS10
39/53
39
Examplevoid function eval (int A, int B, int X )
{
if ( A > 1) and ( B = 0 )
then X = X / A;if ( A = 2 ) or ( X > 1)
then X = X + 1;
}Statement coverage test cases:
1) A = 2, B = 0, X = 3 ( X can be assigned any value)
-
7/29/2019 Materi TIS10
40/53
40
Decision coverage write test cases to exercise the true and false
outcomes of every decision
TER2 = branches exercised / total branches
Condition coverage write test cases such that each condition in a
decision takes on all possible outcomes atleast once
may not always satisfy decision coverage
White Box Test-Case Design
-
7/29/2019 Materi TIS10
41/53
41
Examplevoid function eval (int A, int B, int X )
{
if ( A > 1) and ( B = 0 ) then
X = X / A;if ( A = 2 ) or ( X > 1) then
X = X + 1;
}
Decision coverage test cases:
A > 1
andB = 0
A = 2or
X > 1
X = X+
X = X/
a
cT
Fb
eT
Fd
2) A = 2, B = 1, X = 1 (abe)
1) A = 3, B = 0, X = 3 (acd)
-
7/29/2019 Materi TIS10
42/53
42
ExampleCondition coverage test cases must
cover conditions
A>1, A1, X 1andB = 0
A = 2or
X > 1
X = X+
X = X/
a
cT
Fb
eT
F
d
-
7/29/2019 Materi TIS10
43/53
43
White Box Test-Case DesignDecision Condition coverage write test cases such that each condition in a decision takes
on all possible outcomes at least once and each decisiontakes on all possible outcomes at least once
Multiple Condition coverage write test cases to exercise all possible combinations of
True and False outcomes of conditions within a decision
-
7/29/2019 Materi TIS10
44/53
44
ExampleDecision Condition coverage test
cases must cover conditions
A>1, A1, X 1 and B = 0) T, F
( A = 2 or X > 1) T, F
Test cases:1) A = 2, B = 0, X = 4 (ace)
2) A = 1, B = 1, X = 1 (abd)
A > 1andB = 0
A = 2or
X > 1
X = X+1
X = X/ A
a
cT
Fb
eT
F
d
-
7/29/2019 Materi TIS10
45/53
45
ExampleMultiple Condition coverage must cover conditions
1) A >1, B =0 5) A=2, X>12) A >1, B !=0 6) A=2, X
-
7/29/2019 Materi TIS10
46/53
46
Basis Path Testing1. Draw control flow graph of program from the program
detailed design or code.
2. Compute the Cyclomatic complexity V(G) of the flow
graph using any of the formulas:V(G) = #Edges - #Nodes + 2
or V(G) = #regions in flow graph
or V(G) = #predicates + 1
-
7/29/2019 Materi TIS10
47/53
47
Example
1
2
3
4
5 10
6
7
8
9
R4
R3
R211
12
13
R1
R6
R5
V(G) = 6 regions
V(G) = #Edges - #Nodes
+ 2 = 17 - 13 + 2 = 6
V(G) = 5 predicate-nodes
+ 1 = 6
6 linearlyindependent paths
-
7/29/2019 Materi TIS10
48/53
48
Basis Path Testing (contd)3. Determine a basis set of linearly independent paths.
4. Prepare test cases that will force execution of each path in
the Basis set.
The value of Cyclomatic complexity provides an upper bound on
the number of tests that must be designed to guarantee coverage
of all program statements.
http://testing2_iitkh.ppt/http://testing2_iitkh.ppt/ -
7/29/2019 Materi TIS10
49/53
49
Loop TestingAims to expose bugs in loops
Fundamental Loop Test criteria1) bypass the loop altogether
2) one pass through the loop
3) two passes through the loop before exiting
4) A typical number of passes through the loop, unlesscovered by some other test
-
7/29/2019 Materi TIS10
50/53
51
Data Flow TestingSelect test paths of a program based on the Definition-Use
(DU) chain of variables in the program.
Write test cases to cover every DU chain is at least once.
-
7/29/2019 Materi TIS10
51/53
52
Thank You
Any Questions ????
-
7/29/2019 Materi TIS10
52/53
Question
??
-
7/29/2019 Materi TIS10
53/53
Thank you