Documente Academic
Documente Profesional
Documente Cultură
Software Testing
[Marks : 75
al
a
nk
ar
Vi
dy
1014/BSc/IT/TY/Pre_Pap/2014/ST_Soln
[5]
Acceptance
Testing
SYSTEM
ANALYSIS
System
Design
Software
Code
System
Testing
S/w
Testing
TEST
LEVELS
ar
S/w
DEVELOP
MENT
LEVELS
Integration
Testing
Unit
Testing
dy
al
a
nk
Vi
a1 : Not a
a2 : Eq. V
a3 : Fso
a4 : satan D
a5
:
Impossible
Action
stab
T
F
T
T
F
T
T
T
F
F
F
T
T
T
F
F
T
T
T
T
F
T
F
T
T
T
F
T
T
T
T
T
T
F
F
T
T
T
T
F
T
T
T
T
T
T
F
T
T
T
T
T
T
ar
Condition
stab
nk
C1 : a < b + c
C2 : b < a + c
C3 : c < a + b
C4 : a = b
C5 : b = c
C6 : a = c
Vi
dy
al
a
ar
Characteristics of Software :
1) Software cannot be manifctured, it is always developed in classical
sense.
2) Software does not wareout i.e. software can be upgrade or modified
3) Availability : Software should be easily available to all user.
4) Reliability
5) Flexibility
6) Security
7) Useability
8) Maintainability
9) Portability
Vi
dy
al
a
nk
Begin
nk
Planning and
ar
[5]
Control
al
a
Implementation and
Execution
Vi
dy
end
[10]
[5]
ar
Need wish,
policy laws
User Requirement
Global Design
nk
System Requirement
Detailed Design
al
a
Vi
dy
nk
ar
Executable are tested as per the test plan in system testing. The software
are executed to find bugs defects present if any
Finally successful software is deployed to the costume and future activities
are handled through maintain advantages :
1) It is one of the oldest systematic & sequential approach towards
software development.
2) All the phases of software development are clearly defined i.e., Each
team member should know when his/her responsibility in development
process.
3) It is one of the time consuming model because ones requirements are
gathered from costumer, the work model is available only after the
deployment. Costumer needs to specify all their requirements software
development but it is often difficult for any costumer to give all their
requirements explicitly.
Vi
dy
al
a
BBT
WBT
ar
nk
Vi
dy
al
a
2) Integration Testing :
Once all the modules are tested properly. Tester needs to integrate
them as per the design of software to ensure that it will work
properly as whole
There are two types of Integration testing i.e.
Top down Integration
Bottom up Integration
In top down integration one by one module gets added in system
where as in bottom up integration is conducted cluster by cluster
integration.
Regression testing is perform along with integration testing to
ensure that system will perform properly whenever there is any
change in software.
Integration testing test interfaces between components, interaction,
to different parts of system such as an o. s., file system &
interfaces between software & hardware.
Integration testing is after carried out by integrator but preferably
by specific integration tester or testor team depending on structural
requirement of system. Integration testing can be categorized as
follows
a) Top Down Integration :
In these, testing takes place from top to better following the
control flow or architectural structure e.g. starting from GUI or
main menu.
Components or system are substituted by staff.
b) Bottom Up Integration
Bottom up testing takes place form bottom of control flow upwards.
dy
al
a
nk
ar
3) System testing :
It is concerned with behavior of whole system or product as defined
by the scope of development project or product
System testing may include test based on requirement specification,
business process, use cases, system behavior, interactions with
operation system & system resources.
System testing is most often the final test on behalf of development
to verify that the system to be delivered meets specification and its
purpose may be to find as many defects as possible.
Most oftenly system testing is curried out by specialist testor from
independent third party
System testing should investigate both functional & Nonfunctional
requirements of the system. Typically nonfunctional requirement
includes performance & reliability system testing of functional
requirement starts by using most appropriate specification based
technique (BBT) for aspect of the system to be tested.
The following are testing to be conducted during system testing
1. Performance testing
2. Load/Stress
3. Recovery
4. Security testing
Vi
4) Acceptance Testing :
When development organisation has perform its system test & has
corrected or all most defects, the system will delivered to user or
costumer for acceptance testing these test should answer following
question such as
a) Can system be released?
b) What if any are the outstanding risk?
c) Has development meet their expectations?
It is most often the responsibility of user & costumer, although
other stoke holder may be involves as well. The goal of acceptance
testing is to be established a confidence in the system, part of the
system or specific nonfunctional characteristics.
e.g. Useability of system
Vi
dy
al
a
nk
ar
10
2.
3.
4.
5.
6.
ar
1.
nk
To
al
a
1.
Vi
dy
11
A)
B)
C)
ar
i)
ii)
dy
al
a
nk
Vi
2) KICKOFF
i) An optional step in review process in kick off meeting the goal of
these meeting is to get everybody on same wavelength regarding
document under review & to commit to time that will be spent on
checking.
ii) Also the result of entry check & exit criteria are discussed in case
of more formal review.
iii) Roll assignment, checking rate, the pages to be check process
changes & possible other questions regarding formal reviews are also
discuss during this meeting.
12
3)
The participants who are individualy on document under review using
the related documents, procedure rules & checklist proper. The
individual participant identify defects according to their
understanding of document & role.
ii) All issues are recorded preferably using logging form spelling
mistakes are recorded on document under review but not mentioned
during review meeting.
iii) A critical success factor for thurrow preparation is no. of pages
checked per hour, these is called Checking Rate.
ar
i)
Vi
dy
al
a
nk
4) REVIEW MEETING:
i) Logging Phase:
Discussion Phase
Decision Phase
During logging phase, the issues e.g. defects that have been identified
during preparation phase are mention phase by phase, reviewer by
reviewer & are logged either by author or recorder.
A separate person like recorder or scriber is present in logging phase to
log defects encouraged during review process.
To ensure process & efficiency, no real discussion, the items are logged
& then handled in discussion phase. A detailed discussion on whether or
not an issue is defects is not meaningful, as it is much more efficient to
simply log it & proceed to next defect.
During logging phase the focus is on logging as many defects as possible
within certain time frame.
To ensure these, moderator tries to keep good logging rate i.e. no. of
defects logged per minute.
As chairperson of discussion meeting the moderator takes care of
peoples issues. All the defects logged in previous phase are discussed in
detail during discussion phase.
At the end of meeting a decision on document under review has to be
made by participant based on formal exit criteria. The most important
exit criteria is no. of critical or major effect is avg. no. of major or
critical defect found per page.
5) REWORK:
Based on defects detected, author will improve document under review
stepbystep. Not every defect i.e. found leads to rework. It is the
authors responsibility to judge if defects has to be fixed. If no. of
13
defects per page exceeds the exit criteria then only the rework should
be conducted for author.
ar
6) FOLLOWUP:
The moderator is responsible for ensuring that satisfactory action have
been taken on all logged defects, process improvement suggestion &
change request. Although the moderator checks to make sure that
author has taken action an all defects, it is not necessary for moderator
to check all corrections in detail for more formal review type moderator
checks only for complains to exit criteria i.e. during followup moderator
keeps track on those errors which are encountered during logging phase
& their elimination process.
Vi
dy
al
a
nk
ar
Reviewer:
The task of reviewer is to check authors documents for defects the levels
of domain knowledge or technical expertise needed by reviewer will depend
on type of review & type of document which is under review.
The reviews should be chosen to represent different prospective & rates in
review process. In addition to document under review the material reviewer
reviews includes source, standards, checklist etc. The sole responsibility is
to review authors document & try to find as many defects as present in
document.
nk
Manager:
The manager is involved in reviews as he/she decides on execution of
reviews, allocates time in project schedules & determines whether review
process object have been met. The manager is also responsible for providing
readymade tools, review training if requested by participants.
Vi
dy
al
a
Vi
dy
al
a
nk
ar
Inspection :
1. Inspection is most formal review type, the document under inspection is
prepared & check thoroughly before meeting, comparing work
product with its sources & other referenced documents, & using
rules & checklist as inspection is validation criteria (Acceptance
testing)
Checklist mechanism is must
2. In inspection meeting defects found are logged & any discussion is
postponed until discussion phased, these makes inspection meeting
very efficient meeting
3. In inspection meeting all defects are discussed, solve, & make a decision
on them whether to accept or reject inspection is performed by an
inspector.
Using checklist mechanism
The goals of Inspections are
1. To help author to improve the quality of documentation under
inspection
2. To remove defects efficiently, as early as possible.
3. To remove defects efficiently, as producing documents with higher
level of quality
4. To train new employer in organisations development process.
Key Characteristics of Inspection are
1. It is usually led by trained moderator
2. It uses define goal using process
3. If involves peer to peer common to examines product
4. Rules & checklist are use during preparation phase
5. Defects found are documented in logging list or issued log
6. Follows up is carried out by applying exit criteria.
16
ar
Static analysis is an examination of req. design & code which differs from
dynamic testing in no. of following ways
1. Static analysis is perform on requirement, design or code without
actually executing s/w being examine
2. It is ideally perform before types of formal reviews
3. Static analysis unrelated to dynamic properties of requirements, design
& code such as test coverage
4. The basic goal of static analysis is to find defects whether or not they
may cause failures
Vi
dy
al
a
nk
17
nk
ar
Vi
dy
al
a
18
nk
ar
objects. The first step is to translate source code into control flow
graph.
The graph makes it easier to specify in detail the control elements that
must be covered in a graph the statements are represented as node a
control flow between statement are resented by edges if sequences of
unidirectional statement appear in program fragment then they are
illustrated as one single node.
Conditional statements like if.else & loops like while, do ..while have
more than one edges going out from them.
After execution of test cases it must be verified which of the
statements have been executed. Statement coverage must ensure that
each & every statement of a program must be executed at least once.
The test completion criteria for s.c. can define as
No.ofexecutableStat.
State Coverage =
x100
ofstat.
Totalno.
dy
al
a
2) Branch Coverage:
A more advance criteria for white box testing is branch coverage of
control flow graph.
e.g. Edges in the graph are Centre of tension. Execution of each
statement is not consider during branch coverage but rather the
execution of decisions are more important.
The result of decision determines which statement is executed next.
Branch coverage testing should make sure every decision with both
possible outcomes i.e. true & false.
Test complition criteria for branch coverage is defined a
No.ofexecutablebranches
x100
Branch Coverage =
Totalno.
ofBranches
Vi
3) Path Coverage:
Until now test case determination focused on statement or branches of
control flow as well as complexity repeatitions, the previous
deliberations are not sufficient or not adequate test, path coverage
requires execution of all different paths through test objects.
The test completion criteria for P.C. cannot define mathematically
because it will depends on no. of repeation of loop.
No. of path coverage of test object can be determine using cyclomatic
caomplexity, which gives total no. of maximum paths available in control
flow.
19
Vi
dy
al
a
nk
ar
Vi
dy
al
a
nk
ar
21
ar
Vi
dy
al
a
nk
1) Error Guessing:
It is a technique that should always be use as complement to other more
formal technique the success of error Guessing is very much depend on
skill of tester, as good tester knows where the defects are most likely
to occur.
Some people seem to be naturally good at testing as they have
experience in testing of variety of software. Error guessing approach is
used after more formal techniques that have been applied to same
extent can be very effective.
In these technique the tester is likely to gain better understanding of
system what is does & how it does, & with these better understanding
the tester is likely to be better at guessing ways in which the system
may not work properly.
There are no rules for error guessing.
The tester is encourage to think of situations in which s/w may not be
able to code.
Typical conditions to try includes division by zero, blank I/P , empty files
and wrong data I/P if anyone even says a system or environment in which
s/w is not operate then error guessing is first methodology to operate
software.
By using error guessing tester can find no. of errors by his own
experience or common sense approach. Error guess methods saves a lot
of time during testing.
2) Exploratory Testing:
It is hands on approach in which testers are involve in minimum planning
& maximum test execution planning involves creation of test cases, a
short declaration of scope, objectives & possible approaches to be used,
where as test design & execution activities are performed in parallel
without formally documenting test condition or test cases.
22
It is most useful when there are no or poor. Specifications & when time
is severally limited it can be use as check on the formal test process by
helping by ensure that most serious defects have been found.
In exploratory testing the cases prepared by s/w tester based on their
past experience of testing similar application based software.
Vi
dy
1)
2)
3)
4)
5)
al
a
nk
ar
23
<<include>>
Issue
Return Book
Verify Library
card
<<include>>
Pay Fine
Read Newspaper
Study/assignment
Collect
Maintain Books
Stock
Prepare list of
books
Order book
Make payment
Place order
Cost estimation
Verify order
Verified
Supply book
al
a
<<extend>>
Place order
nk
Maintain Students
record
Librarian
ar
Internet access
Student
Supplier
Vi
dy
24
Daring text execution & as project winds down they write summary reports
on test states. Sometime test leaders wear diff., titles, such as test
management or test Coordinator.
al
a
nk
ar
Vi
dy
25
al
a
nk
ar
Vi
dy
26
al
a
nk
ar
dy
Test management tools are use to manage entire test process. It starts
from test data preparation, test data exaction towards the preparation of
final result of how many test & outstanding.
The features or characteristics of test management tools are
1. Management of test
2. Scheduling of test to be executed (manually or by a test execution
tools).
3. Management of testing activites (time spent in test design, test
execution whether we are on schedule or.
Vi
27
nk
ar
al
a
dy
1.
2.
3.
4.
5.
6.
7.
Vi
Q.7(d) Explain reporting and characteristics of unit test tools and security [5]
tools.
(A)
Unit test framuvark tool is use to perform unit testing on software
component
Features / Characteristic includes
Supplying inputs to the unit/ module of software
Receiving o/p generated by unit of software
Which are being tested
Executing set of test cases on s/w unit
Record the result of each test case performed on each unit using pass or fail
basis
Storing the result of test cases
Support for debugging
Covering measurement at code level
28
nk
ar
Security tools :
There are number of tools that protect system from external attack for
e.g. firewalls, which are important for any system security testing tools can
be used to test security by trying to break into systems whether or not it is
protected by a security tool.
The attack may focus on the network the software support, the application
code or underlying database.
Features or characteristics of security testing tools includes support for :
1. Identifying softwares.
2. Detecting instructions such as deniel of service attacks
3. Simulating various types of service attack
4. Probing for open ports or other externally visible points of attacks
5. Identifying weakness in password files & passwords
6. Security cheeks during operation. E.g. for checking integrity of files &
intrusion detection e.g. checking result of test attacks.
Vi
dy
al
a
29
[5]
ar
al
a
nk
Vi
dy
30