0% found this document useful (0 votes)
333 views69 pages

Testing Techniques

White box testing involves knowledge of internal code structure and logic, while black box testing does not. White box techniques include unit testing, path testing, branch testing, and statement coverage testing. Black box testing uses equivalence partitioning to divide inputs into valid and invalid classes to design test cases based on expected functionality without seeing code.

Uploaded by

Sachin Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
333 views69 pages

Testing Techniques

White box testing involves knowledge of internal code structure and logic, while black box testing does not. White box techniques include unit testing, path testing, branch testing, and statement coverage testing. Black box testing uses equivalence partitioning to divide inputs into valid and invalid classes to design test cases based on expected functionality without seeing code.

Uploaded by

Sachin Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 69

TESTING TECHNIQUES

BLACK BOX TESTING WHITE BOX TESTING


• The internal structure or the program • The tester has knowledge about the
or the code is hidden and nothing is internal structure of the code or the
known about it. program of the software.
• It is mostly done by software testers. • It is mostly done by software
• No knowledge of implementation is developers.
needed. • Knowledge of implementation is
• It can be referred as outer or external required.
software testing.
• It is the inner or the internal software
• It is functional test of the software. testing.
• This testing can be initiated on the
basis of requirement specifications • It is structural test of the software.
document. • This type of testing of software is
• No knowledge of programming is started after detail design document.
required. • It is mandatory to have knowledge of
programming.
• It is the behavior testing of the • It is the logic testing of the software.
software. • It is generally applicable to the lower
• It is applicable to the higher levels of levels of software testing.
testing of software. • It is also called as clear box testing.
• It is also called closed testing. • It is most time consuming.
• It is least time consuming. • It is suitable for algorithm testing.
• It is not suitable or preferred for • Data domains along with inner or
algorithm testing. internal boundaries can be better
• Can be done by trial and error ways tested.
and methods. • Example: by input to check and
• Example: search something on verify loops
google by using keywords • Path testing, branch testing,
• Functional, non functional and statement coverage testing
regression testing
DYNAMIC WHITEBOX TESTING
• We evaluates the code and internal structure of the program.
• The testing of a software solution's internal coding and infrastructure.
• Dynamic white-box testing is used to test the internal design, code , and structure of
a program by running it.
• Its main advantage is the maximum test coverage, the opportunity to find
hidden errors and optimize the code.
• Dynamic white-box testing is focused on three main aspects:
1. Testing of the source code, separate software parts, low-level functions, and
libraries.
2. Integration testing.
3. System testing.
CONTROL FLOW TESTING
• Control flow testing is a testing technique that comes under white box testing.
• Determine the execution order of statements or instructions of the program
through a control structure.
• The control structure of a program is used to develop a test case for the
program.
• A particular part of a large program is selected by the tester to set the testing
path.
• It is mostly used in unit testing.
NOTATIONS USED IN CONTROL FLOW
GRAPH
• Node
• It represents the sequence of procedures which procedure is next to come so, the
tester can determine the sequence of occurrence of procedures.
• Edge
• Edge in control flow graph is used to link the direction of nodes.
• Decision node
• Decision node in the control flow graph is used to decide next node of procedure as per
the value.
• Junction node
• Junction node in control flow graph is the point where at least three links meet.
To indicate a sequence

To indicate for loop

To indicate decision making

To indicate switch case


BASIS PATH TESTING
• Basis path testing involves execution of all logical sequence in a program at
least once.
• The objective behind basis path in software testing is that it defines the
number of independent paths.
• Independent Path
• An independent path is one that represents a path in the program that traces a
new set of procedural statements or conditions.
• Path 1: 1-11
• Path 2: 1-2-3-4-5-10-1-11
• Path 3: 1-2-3-6-8-9-10-1-11
• Path 4: 1-2-3-6-7-9-10-1-11
CYCLOMATIC COMPLEXITY
• Cyclomatic complexity is a source code complexity measurement that is being
correlated to a number of coding errors.
• It is calculated by developing a Control Flow Graph of the code that measures
the number of linearly-independent paths through a program module.
• The cyclomatic complexity V(G) can be calculated with the formulas below:
1.V(G) = E – N + 2  // E is no. of edges in the flow graph, N is no. of nodes in the
flow graph.
V(G) = 11 edges – 9 nodes + 2 = 4
2.V(G) = P + 1   // P is no. of predicate node
V(G) =  3 predicate nodes + 1 = 4
3.V(G)= no. of regions of a flow graph =4
STATEMENT COVERAGE
• Involves the execution of all the statements at least once in the source code.
• Using this technique we can check what the source code is expected to do and
what it should not.
• It is used to calculate and measure the number of statements in the source
code which can be executed given the requirements.
• we cannot test the false condition in it.
Example 1
• Read A
Read B
if A>B
Print “A is greater than B”
else
Print "B is greater than A"
endif
• Set1 :If A =, B =2
• No of statements Executed: 5
Total no of statements in the source code: 7
Statement coverage =5/7*100 = 66 %
Example 2
• Read A
Read B
if A>B
Print “A is greater than B”
else
Print "B is greater than A"
endif
• Set1 :If A =2, B =5
• No of statements Executed: 6
Total no of statements in the source code: 7
Statement coverage =6/7*100 = 85.20 %
•{
input (int X, int Y)
{
Z = ((X + Y) / 200 )* 100
If (Z>50)
{
Print (PASS)
} else
{
Print (FAIL)
}
}
}
input (int
X, int Y)

Z = ((X + Y) /
200 )* 100

If (Z>50)

• Yes No

Print Print
(PASS) (FAIL)
DECISION COVERAGE
• Decision coverage evaluates the true or false outcomes of each Boolean
expression.
• Some times expressions can sometimes get complicated. Therefore, it is very
hard to achieve 100% coverage.
Demo(int a)
{
If(a>5)
a=a*3;
print(a);
else
print(a);
}
• Value of a is 2
The code highlighted in yellow will be executed.
Decision Coverage = 50%
• Value of a is 6
The code highlighted in yellow will be executed.
Decision Coverage = 50%
BRANCH COVERAGE
• Branch coverage is also known as Decision coverage or all-edges coverage.
• It covers both the true and false conditions unlikely the statement coverage.
• A branch is the outcome of a decision, so branch coverage simply measures
which decision outcomes have been tested.
• A decision is an IF statement, a loop control statement (e.g. DO-WHILE or
REPEAT-UNTIL), or a CASE statement, where there are two or more outcomes
from the statement.
Demo(int a)
{
If(a>5)
a=a*3;
print(a);
}
• Prints (int a, int b){
• int result = a+ b;
• If (result> 0)
• Print ("Positive", result)
• Else
• Print ("Negative", result)}
• READ Username
READ Password
IF Count (Username) < 8
PRINT “Enter a Valid Username”
ENDIF
IF Count (Password) < 5
PRINT “Enter a Valid Password”
ENDIF
IF Count(Username & Password) < 1
PRINT “Please Fill the Username & Password Fields”
ELSE
PRINT “Login Successfully”
ENDIF
• Read P
Read Q
IF P+Q > 50 THEN
Print “Large”
ENDIF
If P+Q< 50 THEN
Print “Small”
ENDIF
• Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF

• P=60,Q=50
• P=60,Q=30
• P=30,Q=80
• P=30,Q=60
• P=60,q=50, sc=100%
• P=40,q=50, sc=6/8=75%
• P=60,q=30, sc=7/8=88%
• P=40,q=70, sc=7/8=88%
• READ Username
READ Password
IF Count (Username) < 8
PRINT “Enter a Valid Username”
ENDIF
IF Count (Password) < 5
PRINT “Enter a Valid Password”
ENDIF
IF Count(Username & Password) < 1
PRINT “Please Fill the Username & Password Fields”
ENDIF
ELSE
PRINT “Login Successfully”
BLACK BOX TESTING
INTRODUCTION
• Structure of the program is not considered
• The expected behavior of the system is used to design test cases
• Test cases are decided solely on the basis of the requirements or specifications
• Tester only knows the inputs that can be given to the system and what output
the system should give
• Internal structure of code not used for test case design
• Also called functional or behavioral testing
EQUIVALENCE CLASS
PARTITIONING
• Reduces the huge (or infinite) set of possible test cases into a small, but equally
effective, set of test cases.
• Divides the input domain of a program into classes of data from which test cases
can be derived.
• Test case is based on an evaluation of equivalence classes for an input condition.
• An equivalence class represents a set of valid or invalid inputs for conditions.
• Input condition is either a specific numeric value, a range of values, a set of
related values, or a Boolean condition.
EQUIVALENCE CLASSES FOR RANGE
If an input condition specifies a range, one valid and two invalid equivalence classes are
defined.

Test Case for range


**Valid T1 {Check value between 18-56, User Enter a value from 18 to 56, Age is accepted}
**Invalid T2 {Check value <=17, User Enter value <=17, Age is not accepted}
**Invalid T3 {Check value >=57, User Enter value >=57, Age is not accepted}
EQUIVALENCE CLASSES FOR ABSOLUTE VALUE

If an input condition requires a specific value, one valid and two invalid equivalence
classes are defined.

Test Case for absolute value


**Valid T1 {10 digits 0-9, User enters 10 digit comprising of 0 to 9, Valid mobile no. entered}
**Invalid T2 {<=9, User enters <=9 digit comprising of 0 to 9, Invalid mobile no. is entered}
**Invalid T3 {>=11, User enters >=11 digits comprising of 0 to 9, Invalid mobile no. is entered}
Equivalence Classes for set of Value
If an input condition requires for set of values, one valid and one invalid equivalence
classes are defined. For example we have to take details of student where attendance
is 75, 85, 95

Test Case for range


**Valid T1 {(Any value of 75,85,95), User enters a value like 75,85,95,( Details to be
displayed on the screen)}
**Invalid T2 {(All values other then 75,85,95), User enters value other then 75,85,95,(Details
are not available for input entered)}
Imp – The same is applicable for Boolean value 1 valid class and one invalid class
BOUNDARY VALUE ANALYSIS (BVA)
• Boundary value analysis is a test case design technique that complements
equivalence partitioning.

• Rather than selecting any element of an equivalence class, BVA leads to the
selection of test cases at the "edges" of the class.

• In other word, Rather than focusing solely on input conditions, BVA derives
test cases from the output domain as well.
BOUNDARY VALUE ANALYSIS
• Programmers may improperly use < instead of <=

• Boundary value analysis:


• select test cases at the boundaries of different equivalence classes.
For(i=1;i<10;i++)
{
Printf(i);
}
GUIDELINES FOR BVA
1. If an input condition specifies a range bounded by values a and b, test cases should be
designed with values a and b and just above and just below a and b.

2. If an input condition specifies a number of values, test cases should be developed that
exercise the minimum and maximum numbers. Values just above and below minimum
and maximum are also tested.

3. Apply guidelines 1 and 2 to output conditions.


Example

• For a function that computes the square root of an integer in the range of 1
and 5000:
• test cases must include the values: {0,1,5000,5001}.
• TC1{0,1,5000,5001}
• TC1{17,18,56,57}
• TC1 {5,6,12,13}
• 11906426 TC1 {7,8,8,9}

1 5000
BVA RANGE
• To test a field which accepts Age 18 – 56

• A text field (Name) which accepts the length between 6-12 characters.
DECISION TABLE
• This is a systematic approach where various input combinations and their
respective system behavior are captured in a tabular form.
• Decision table technique is appropriate for the functions that have a logical
relationship between two and more than two inputs.
• This technique is related to the correct combination of inputs and determines
the result of various combinations of input.
• Decision tables are precise and compact way to model complicated logic.
• They are ideal for describing situations in which a number of combinations of
actions are taken under varying sets of conditions.
• It is also known as a cause-effect table.
STRUCTURE OF DECISION TABLE
Example 1
• Most of us use an email account, and when you want to use an email
account, for this you need to enter the email and its associated password.
• If both email and password are correctly matched, the user will be directed to
the email account's homepage;
• Otherwise, it will come back to the login page with an error message
specified with "Incorrect Email" or "Incorrect Password."
Example 2
• A company’s employees are paid bonuses if they work more than
a year in the company and achieve individually agreed targets.
• Conditions:
• Employment for more than 1 year?
• Agreed target?
• Achieved target?
• Actions / Outcome :
• Bonus payment?
Employment more T T T T F F F F
than 1 year?

Agreed Target? T T F F F T F T

Achieved Target? T F F T F T T F

Bonus paid? T F F F F F F F
Employment more Y Y Y N
than 1 year?

Agreed Target? Y Y N -

Achieved Target? Y N - -

Bonus paid? y N n n
Verification is to be done
• You agrees to pay the loan in given time period
• You agrees to pay the loan as per the given interest rate
• You are able to produce some guarantor
• Your credit history or score
You agrees Y Y Y Y y y y y n n n n n n n n
to pay the
loan in
given time
period

You agrees Y Y Y Y n n n n y y y y n n n n
to pay the
loan as per
the given
interest
rate

You are Y Y n n y y n n y y n n y y n n
able to
produce
some
guarantor

You are Y N y n y n y n y n y n y n y n
credit
history or
score
Loan? y
You agrees to Y Y Y Y n
pay the loan in
given time
period

You agrees to Y Y Y n -
pay the loan as
per the given
interest rate

You are able to Y Y N - -


produce some
guarantor

You are credit Y n - - -


history or score

Loan? y
1 Y y y n

2 Y Y N -

3 Y N - -

Result?
1 Y y y y n n n n

2 Y y n n y y n n

3 Y n y n y n y n

Result Y
pay the y y y y y y y y n n n n n n n n
loan in
given time
period
pay the y y y y n n n n y y y y n n n n
loan as
per the
given
interest
rate
able to y y n n y y n n y y n n y y n n
produce
some
guarantor
credit y n y n y n y n y n y n y n y n
history or
score
Loan ye n n n n n n n n n n n n n n n
granted? s
Uid valid invalid blank valid invalid blank valid invalid blank

pswd valid invalid blank invalid valid valid blank blank invalid

Login? successf Error Error Error Error Error Error Error Error
ull message message message message message message message message
Uid valid valid invalid blank valid

pswrd valid invalid - - blank

Login? yes no no no no
REGRESSION TESTING
• A type of software testing to confirm that a recent program or code change
has not adversely affected existing features.

• A full or partial selection of already executed test cases which are re-executed
to ensure existing functionalities work fine.

• This testing is done to make sure that new code changes should not have side
effects on the existing functionalities.
• It ensures that the old code still works once the latest code changes are done.
• Performed whenever there is requirement to change the code and we need to
test whether the modified code affects the other part of software application
or not.
• When a new feature is added to the software application and for defect fixing
as well as performance issue fixing.
CONFIGURATION TESTING
• Checks an application with multiple combinations of software and hardware to
find out the optimal configurations that the system can work without any flaws
or bugs.
• Desktop applications will be of 2 tier or 3 tier, here we will consider a 3 tier
Desktop application which is developed using Asp. Net and consists of Client,
Business Logic Server and Database Server where each component supports
below-mentioned platforms.
COMPATABILITY TESTING
• Compatibility Testing is a type of Software testing to check whether your
software is capable of running on different hardware, operating systems,
applications, network environments or mobile devices.
• Compatibility Testing is a type of Non-functional testing
TYPES OF COMPATIBILITY TESTS
•Hardware: It checks software to be compatible with different hardware
configurations.

•Operating Systems: It checks your software to be compatible with


different Operating Systems like Windows, Unix, Mac OS etc.

•Software: It checks your developed software to be compatible with other


software. For example, MS Word application should be compatible with
other software like MS Outlook, MS Excel, VBA etc.

•Network: Evaluate performance of a system in a network with varying


parameters such as Bandwidth, Operating speed, Capacity. It also checks
application in different networks with all parameters mentioned earlier.
•Browser: It checks the compatibility with different browsers like Firefox,
Google Chrome, Internet Explorer etc.

•Devices: It checks compatibility of your software with different devices


like USB port Devices, Printers and Scanners, Other media devices and
Blue tooth.

•Mobile: Checking your software is compatible with mobile platforms like


Android, iOS etc.

•Versions of the software: It is verifying your software application to be


compatible with different versions of the software. For instance checking
your Microsoft Word to be compatible with Windows 7, Windows 7 SP1,
Windows 7 SP2, Windows 7 SP3.
1.Browser Stack - Browser Compatibility Testing: This tool helps a Software
engineer to check application in different browsers.

2. Virtual Desktops - Operating System Compatibility: This is used to run the


applications in multiple operating systems as virtual machines. n Number of
systems can be connected and compare the results.
USABILITY TESTING
• Measures how easy to use and user-friendly a software system is.

• This testing mainly focuses on the user's ease to use the application, flexibility
in handling controls and the ability of the system to meet its objectives.

• It is also called User Experience(UX) Testing.

• Recommended during the initial design phase of SDLC, which gives more
visibility on the expectations of the users.
FOREIGN LANGUAGE TESTING
• Localization is defined as making a product, application or document content
adaptable to meet the cultural, lingual and other requirements of a specific
region or a locale.

• Internationalization is the process of designing and developing a product,


application or document content such that it enables localization for any given
culture, region, or language.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy