White Box Testing Techniques :
Developers
will use the Fallowing Two Techniques to Ensure 100% Code Coverage During White
Box Testing. They Are
1) Statement Coverage
2)
Path
/Branch/Condition Coverage
Statement
Coverage
The
Percentage Of Statements Exercised During White Box Testing is Called Statement
Coverage.
Statement Coverage
= (No.. Of Statements Exercised / Total No.. Of Statements)*100%
Ex 1:
READ
A
READ
B
IF
A>B THEN
PRINT “A is Big”
END
IF
One TC that is a=10,b=5 is Enough to Ensure
100% Statement Coverage For The Above Example. (3/3*100%=100%)
Ex 2:
READ
A
READ
B
IF
A>B THEN
PRINT “A is Big”
ELSE
PRINT “B is Big”
END
IF
Minimum 2 TC Required ( a=10,b=5 ; a=5,b=10
) to Ensure 100% Statement Coverage For The Above Example. (3/4*100%=75%)
Path /Branch/Condition Coverage :
The
Percentage Of Path Exercised During White Box Testing is Called Path Coverage.
Path Coverage = (No.. Of Path Exercised / Total No.. Of Paths)*100%
Minimum 2 TC Required ( a=10,b=5 ; a=5,b=10
) to Ensure 100% Path Coverage For The Above Example. (1/2*100%=50%)
Note : 100% Path Coverage will
Automatically Ensure 100% Statement Coverage But it is Not Vice Versa.
TC 1 – mon<1 ( Ex – 0 )
TC 2 – mon>12 ( Ex – 15 )
TC 3 - ( 1 to 12)
( Ex – 5 )
100% Path Coverage will Automatically Ensure
100% Statement Coverage But it in the above example Try to do 100% Statement Coverage That will not Cover
100 % Path.
Conclusion : As the Path Coverage
will Automatically Ensure Statement Coverage , It is the Best Technique to
Ensure 100% Code Coverage .
---------------------------------------------------------------
Testing Life Cycle Process
Implementation:
It Is Categorized Into Two Major Activities
A) Test Design ( All Black Box Testing Techniques will Cover
)
B) Test Execution
Test Design (TC Preparation And
Test Data Preparation):
Designing The Test Activities Before The
Actual Testing(Dynamic Or System Testing) Is Carried Out.
All The Test Team Members Would Be Involved
In Test Design Activities.
As Part Of That The First
Activity Performed Is
I) Requirements Analysis:
Which Is Otherwise Called As Requirement
Study
Requirement Analysis Is Understanding The
Complete Requirements Of The Customer.
During This Stage The Project Requirements
Like Business Requirement Specifications(BRS) And The Functional Requirement
Specifications(FRS) Are Published In The Project Server, From Where The Team
Would Access The Documents.
There Would Be A Knowledge Sharing/Transfer
Session Conducted By The Experts(Sme: Subject Matter Experts), For A Better
Understanding On The Requirements.
Incase Of Any Clarifications Or Queries Or
Conflicts During The Study, These Clarifications Can Be Documented And Posted
To The Functional Team Or The Manager Or The Customer For Further
Clarification.
Benefits Of Requirements
Study:
1. A Complete And Thorough Understanding On The Requirements By The Team Would Reduce The
Risk And Reduce Generating The Invalid
Tests, Which Would Reduce The Risk Of Ambiguity In Test Execution.
2. Will Ensure The Complete Test Coverage
With Respect To The Requirements.
Test Design Techniques:
Techniques Are The Fundamentals In Designing
The Tests For Testing A Feature Or A Functionality In An Application.
These Are Predefined And Also Are Called As Black
box Test Design Techniques
There Are 5 Techniques Defined For The Test
Design In Black box Testing, They Are:
A) Boundary Value Analysis(BVA):
It Is Used to Save the time in Length
Testing.
Length Testing : In Length Testing we Have
to Test How Many Characters You can Enter Into a Field .
Implementation Of Boundary Value Analysis:
1) Identify The Boundary(S)
2) Every Boundary Generate Three Conditions
a)
Boundary Value
b)
Boundary Value-1
c)
Boundary Value+1
Any Value Or Condition Outside The Boundary
Should Be Invalid.
Ex : In Login Page User Name Length Should
Be Minimum 4 Characters And Maximum 8 Characters.
B) Equivalence Class
Partitioning(ECP):
It is Used to Save the Time in Value Testing
.
Value Testing : In Value Testing we Have To
Test What values We Can Enter into Field .
Ex : In Login Page User Name Should Accept Only
Alphanumeric in Lower Case.
C) State Transition Testing :
Every
S/W Application will have various States (User Interfaces or Screens ) . An
Application State will Changes From One state to Another Based on Input Data
and Operations You Carryout on the System . State Transition Testing Help Full
to Check All Possible States of the Application .
Ex :
Prepare TC to Check A Customer Account
Access Functionality in ATM Software Using State Transition Testing.
TC1 : Check Customer Account Access By
Inserting a Valid Card and Entering Correct Pin at 1st Try.
TC2 : Check Customer Account Access By
Inserting a Valid Card and Entering Wrong Pin at 1st Try and
Entering Correct Pin at 2nd
Try.
TC3 : Check Customer Account Access By
Inserting a Valid Card and Entering Wrong Pin at 1st and 2nd Try and Entering Correct
Pin at 3rd Try.
TC4 : Check Customer Account Access By
Inserting a Valid Card and Entering Wrong Pin at 1st , 2nd and 3rd Try.
TC5 : Check Customer Account Access By
Inserting a Invalid Card.
D) Decision Table Testing :
It
is Help Full to Determine Defects Because of Mistakes Committed While
specifying the Logical Operators in Code.
Decision
Table Testing is Help Full to Ensure 100% Test Coverage when a Functionality is
Depending on Multiple Inputs. According to Decision Table Testing Number of TC
You Prepared to Ensure 100% Coverage in 2n Where n is number of
Inputs.
As Per Decision Table Testing You Can Derive
the Fallowing TC to Check Login
TC1 : Check Login with Valid username And
Valid password.
TC2 : Check Login with Valid username And
Invalid password.
TC3 : Check Login with Invalid username And
Valid password.
TC4 : Check Login with Invalid username And
Invalid password.
Decision Table For Login
|
Inputs
|
Cond 1
|
Cond 2
|
Cond 3
|
Cond 4
|
|
User Name
|
Valid
|
Valid
|
Invalid
|
Invalid
|
|
Password
|
Valid
|
Invalid
|
Valid
|
Invalid
|
|
Results
|
Display
Inbox
|
Display
Error
|
Display
Error
|
Display
Error
|
E) Use case Based Testing:
The Tests Developed Based On The Use Cases.
In A Usecase A Functionality Or Feature Would Be Described With Both Primary Flow(Positive
Flow) Of Events And The Alternate Flow(Negative Flow) Of Events.
For Every Possible Positive Flow And
Negative Flow, There Should Be A Test Defined.
Note: Often We Perform Use
case Based Testing If The Use cases Are Available.
Use Case:
A Use Case Is A Sequence Of Steps With The
Complete Set Of Primary Flow Of Events Along With The Alternate Flow Of Events
Documented For A Given Requirement.
( It is a Brief Description Of Actor Actions
and System Responses )
Use cases Can Be Part Of Functional
Requirement Specifications, Use case Are Prepared By The Requirement Collection
Team.
Benefits Of Use Cases:
1. Use case Gives A Complete Understanding
On The Functionality Or A Requirement
2. They Are Considered To be The Powerful Sources For Designing The Test Cases
3. Complete Coverage In Testing Can Be
Achieved Based On The Use Cases.
Use case Template:
Use case Number:
It Is
An Unique Identifier Of The Use Case
Ex: Uc 1.0
Use case Name:
Ex: Payments
Actor:
The User Involved In Performing That Feature
Or Functionality On The System
Action Performed:
The Operation Performed On The System By The
User
Ex: Enter User Name In Login Page
Primary Flow:
All The Positive Set Of Events In Performing
The Above Identified Transaction, It Consists Of The Complete Navigation With A
Proper Start And End Positions In Achieving That Functionality Along With The
System Responses And Validations.
Alternate Flow:
The Negative Set Of Events In Performing
That Functionality.
Error Conditions:
The System Responses For The Alternate Flow
Of Events Performed.
Author:
The Person Responsible For Designing The Use
case
Priority:
It Defines The Importance Of The Use case,
Generally It Is Categorized Into Three:
High, Medium And Low
The Tests Are Designed Based On The Priority
Of The Use Case.
Date:
Date On Which The Use case Is Derived.
-----------------------------------------
Test Scenario:
It Is Low Level User Requirement Or A Test
Condition Or A Lowest Component Of A Requirement Which Cannot Be Split Any
Further.
Test Scenarios Are Documented In A MS Word
Or An Excel Document, Where Every Test Engineer Is Involved In.
Test Scenarios Are Identified After The
Requirement Study In The Test Life Cycle Process Implementation.
The Inputs For Identifying The Test
Scenarios Are Business And Functional Requirement Specifications.
Benefits Of Test Scenarios:
1. Will Ensure The Test Coverage With
Respect To The Requirements.
2. Will Give An Estimate Of Number Of Tests To
be Derived For A Given Feature Or Functionality.
No comments:
Post a Comment