Professional Documents
Culture Documents
U6 Software Testing
U6 Software Testing
• Fault –
• The result of an error being made is a fault.
• It is something that is wrong in the software
• (source code or documentation – specifications, manuals, etc.).
• Faults are also known as defects or bugs.
• Failure –
• When a system or piece of software
• produces an incorrect result or does not perform the correct action.
• Failures are caused by faults in the software.
Testing Principles
Testing Objectives
• Testing is
• We begin by ‘testing-in-the-small’
• And
• move toward ‘testing-in-the-large’
Testing Strategies for Conventional Software
1. Unit testing
2. Integration testing
• Non-incremental integration
- big-bang approach
• Incremental integration
- top down testing, bottom up integration, regression
testing, smoke testing
3. Validation testing
- acceptance testing
- alpha testing, beta testing
4. System testing
- recovery testing, security testing, stress testing
performance testing
Phases of Testing
1. Unit Testing
• A unit is the smallest testable part of software.
• In procedural programming
- a unit may be an individual program, function, procedure,
etc.
• In object-oriented programming,
- the smallest unit is a method, which may belong to
- a base/ super class, abstract class or derived/ child class.
• Individual components are tested independently
• Driver –
- a program,
- that accepts the test data & prints the relevant results
• Stub –
- a subprogram,
- that uses – module interfaces
- and
- performs minimal data manipulation
- If required
Unit Testing
module
to be
tested
results
software
engineer
test cases
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
BENEFITS (Advantages) of Unit Testing
• Unit testing
- increases confidence in changing/ maintaining
code.
• Uncovers errors in –
Options:
• the “big bang” approach
• an incremental construction strategy
Approaches of Integration Testing
• Non incremental integration
- big-bang approach
• Incremental integration
- top down testing
- Bottom up testing
- Regression testing
- Smoke testing
Non Incremental Integration
(Big-bang Approach)
• Steps –
• Disadvantages –
- Hard to debug
- difficult to isolate errors while testing
Incremental Integration
- top down integration testing
- Bottom up integration testing
- Regression testing
- Smoke testing
Top Down Integration
B F G
D E
Bottom-Up Integration
B F G
D E
35
Regression Testing
• re-execution of some subset of tests
• that have already been conducted
- to ensure that
- changes have not propagated
- unintended side effects or additional errors
• steps:
• Definition by ISTQB
system testing:
- The process of testing an integrated
system
- to verify that it meets specified
requirements.
• The system test is
• Interoperability testing
• Scalability testing
Types of System Tests
• Recovery testing
- System’s ability to recover from failures.
• Security testing
- Verifies the protection mechanism,
– unauthorized internal or external access,
- or willful damage.
• Stress testing
- Software is tested at highest load, than normal
working environment
- i.e. system is executed for –
resources in abnormal quantity, frequency or
volume
• Performance testing
- runtime performance of the software is evaluated.
- resource utilization is measured.
- such as – CPU load, throughput, response time,
memory usage.
- ex. Beta testing
Acceptance Testing
Acceptance Testing
• Usually,
- it is the members of Product Management,
Sales and/or Customer Support.
• External Acceptance Testing
• is performed by people
• who are not employees of the organization that
developed the software.
• During Record ,
- test steps are captured by the automation
tool.
• During playback,
- the recorded test steps are executed
- on the Application Under Test.
- Example of such tools - QTP .
Model Based Testing
• A model is a graphical description of system's
behavior.
• TC 01- Verify that the text box with the label "Source Folder" is aligned properly.
• TC 02 - Verify that the text box with the label "Package" is aligned properly.
• TC 03 – Verify that label with the name "Browse" is a button which is located at
the end of TextBox with the name "Source Folder.“
• TC 04 – Verify that label with the name "Browse" is a button which is located at
the end of Text Box with the name "Package.“
• TC 05 – Verify that the text box with the label "Name" is aligned properly.
• TC 06 – Verify that the label "Modifiers" consists of 4 radio buttons with the name
public, default, private, protected.
• TC 07 – Verify that the label "Modifiers" consists of 4 radio buttons which are
aligned properly in a row.
• TC 08 – Verify that the label "Superclass" under the label "Modifiers"
consists of a dropdown which must be proper aligned.
• TC 10 – Verify that clicking on any radio button the default mouse pointer
must be changed to hand mouse pointer.
• TC 13 - Verify that the error must be generated in the RED color wherever
it is necessary.
• Selenium
• QTP
• Cucumber
• SilkTest
• TestComplete
• Squish GUI Tester
Web Based Application Testing
Components of Web Based Testing
• Functionality Testing
- Tests, whether all functionalities of that web
applications are working properly
• Usability Testing
- Testing from users perspective
- Content checking
• Interface Testing
- Tests Interfacing of web application with other systems
- Testing of data flow to other system
• Compatibility Testing
- Tests Compatibility of web application
- with different software, operating systems, hardware
etc.
What is Verification?
• The process of evaluating software to determine
• Validation
• is the process of checking whether
• the specification captures the customer’s needs.
• “Did I build what I said I would?”
• Are we building the right system?
Verification Validation
2. It does not involve executing the code. 2. It always involves executing the code.
6. It can catch errors that validation cannot 6. It can catch errors that verification cannot
catch. It is low level exercise. catch. It is High Level Exercise.
• Steps –
94
1. Design flow graph
for the program or a component
• Graphical representation of control flow of the
program
• Contains –
2. CC = E – N + 2
= number of edges – number of nodes + 2
or
97
3. Select Basis set of Path
Since V(G) = 4,
3 there are four paths
4
5 6 Path 1: 1,2,3,6,7,8
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
7 Finally, we derive test
cases to exercise these
paths.
8
4. Generate Test Cases For This Paths
Test Test Test Test steps Test Test Defe
case case case case priorit ct
id name descript status y seve
step Expected Actual
ion (pass rity
/fail)
1
5
What is Test case?
• A test case is a document, which has -
- a set of test data, preconditions,
- expected results and post conditions,
• Test Case acts as the starting point for the test execution,
- and after applying a set of input values,
- the application has a definitive outcome and
- leaves the system at some end point or also known as
execution post condition.
Format of Standard Test Cases
(Below is format of a standard login Test case )
Test
Case Actual
Test Expected Pass
ID Test Steps Test Data Result
Scenario Results /Fail
s
Check
1.Go to site
Custome Userid =
http://demo.guru99.com User should As
r Login guru99
TU01 2.Enter UserId Login into Expect Pass
with Password
3.Enter Password application ed
valid = pass99
4.Click Submit
Data
Check
1.Go to site
Custome Userid = User should
http://demo.guru99.com As
r Login guru99 not Login
TU02 2.Enter UserId Expect Pass
with Password into
3.Enter Password ed
invalid = glass99 application
4.Click Submit
Data
• Below are the standard fields of sample test case template:
• Test Title/Name:
- Test case title.
- E.g. verify login page with valid username and password.
• Pre-condition:
- Any prerequisite that must be fulfilled
- before execution of this test case.
- List all pre-conditions in order to successfully execute this test case.
• Dependencies:
- Mention any dependencies on other test cases or test requirement.
2. Control Structure Testing
• Condition testing —
- a test case design method
- that exercises the logical conditions
- contained in a program module
- ex. Testing of Loops, Branching, Switching statements
Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
Loop Testing: Simple Loops
output
input events
Black Box Testing - Techniques
1. Equivalence Partitioning
• Equivalence classes
- are evaluated for given input condition
114
1. If an input condition specifies a range,
- one valid and two invalid equivalence classes
- are defined
– Input range: 1 – 10
• By Creating –
• Graph of
- objects and their relationships,
(a)
Here - “objects” can be
data objects,
traditional components new menu select generates document
(modules), and object- file (generation time 1.0 sec) window
oriented elements of
computer software.
allows editing
of Attributes:
is represented as
contains
document background color: white
tex text color: default color
t or preferences
(b)
object Directed link object
#1 (link weight) #2
Node weight
Undirected link
(value
)
Parallel links
object
#
3
(a)
allows editing
of Attributes:
is represented as
contains
document background color: white
tex text color: default color
t or preferences
(b)