0% found this document useful (0 votes)
113 views33 pagesSoftware Testing Question Paper
Uploaded by
VIMALCopyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
113 views33 pagesSoftware Testing Question Paper
Uploaded by
VIMALCopyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
/ 33
University of Madras
B.Sc. (CS)
April 2011 SO419/SAZ6CISERG
Time: Three hours Maximum: 75 mike
tk:
SECTION A- (10x 2=20 marks)
Answer any TEN questions.
All questions carry equal marks,
Define Software.
Give the purpose of testing.
Why bug arises?
What is meant by a graph?
How to prepare the format for the test plan?
Define test cases.
Mention the types of testing.
Why testing is difficult?
Give the expansion of SQA.
10. Define Path
11. How error differs from a bug?
12. Give any two importances of decision tables,
pen ar eer
SECTION B (5 x5=25 marks)
Answer any FIVE questions,
All questions carry equal marks
13. How to maintain the quality in software?
14. Explain the technique of creating design style.
15. What is meant by path instrumentation?
16. Explain the concept of path testing.
17. Give the importance of domain testing.
18. Explain the concept of structural metrics.
19. How decision stables can be used for logic testing?
SECTION C (3 x 10= 30 marks)
Answer any THREE questions
All questions carry equal marks
20. What is Bug? Discuss its types.
21, Discuss on transaction flow testing techniques.
22, How data flow testing strategies can be strengthened?
23. With an example, show how syntax testing is done.
24. Discuss the following:
(@) Transaction Testing (b) State Testing. 4 Question Papers g
yt a
lt of fuarat Andra .
se University of Madras so
188e. (C8)
soa SEE
7 TACISEESBISEUGG
13.
14.
15.
16.
17.
18,
19.
2
a.
22.
23.
m4.
). Lisl
Maxitourn: 75 marks
SECTION A- (102020 marks)
“Answer any TEN questions
All questions carry equal marks,
ppefine Quality in olive,
what do you mean by Bug!
what are the various testing styles?
pefin fow graph ;
phat is called Transactions?
Mention the various testing strategies,
Define Path
rite note on syntax testing,
What is 4 path expression?
1 out the various formats of testing,
‘What are the contents in decision table?
Define State Graph.
SECTION B (5 75=25 marks)
“Answer any FIVE questions
All. questions carry equal marks
Compare and contrast the functions of testing and debugging.
Discuss in brief about types of bugs.
Deseribe about transaction system properties.
Write short notes on Domain Testing,
Explain in brief about path expression and path products.
Discuss in brief about logic based testing.
Write notes on Transition testing.
SECTION C (3 »10= 30 marks)
“Answer any THREE questions
All questions carry equal marks
Write an overview about the following:
(a) Model for Testing.
(b) Consequence of Bugs.
Explain in detail about application of path testing.
Describe about dataflow testing strategies.
Discuss about structural metric and linguistic metric.
Write a detailed note on state testing. April 2011
Time: Three hours
1
4,
5.
University of Madras
B.Sc. (CS)
50419/SAZ6CISEESBISEUGG
Maximum: 75 marks
SECTION A- (10 x2=20 marks)
Answer any TEN questions.
All questions carry equal marks,
Define Software,
The logical components of a computer are called software,
Or, a collection of programs is called software. A set of programs is
also called software.
Give the purpose of testing,
© Testing consumes atleast half of the time and efforts
Tequired to produce a functional program.
© MYTH: Good
Programmers write code without any bugs,
(It’s wrong!!!)
History says that even well written programs still have 1-3
bugs per hundred statements,
Why bug arises?
Most bugs arise from mistakes and errors made by people
in cither a program's source code or its design, and a few are caused
by compilers producing incorrect code,
What is meant by a graph?
A graph is a pictorial representation of a Program and not
the program itself, just as a topographic map.
How to prepare the format for the test plan?
A test plan is a document detailing a systematic approach
to testing a system such as amachine or software. The plan
typically contains ‘a detailed understanding of what the
eventual workflow will be.
Define test cases,
A test case it
in software engineering is a set of conditions or
variables under
eS which a tester will determine whether
an application or software systems is working correctly or not.
Ne ith Answve
Unie 2
Fe ay
7, Mention the types of esting
e Functionality testing
2 Forced error testing
© Compatibility testing
© Performance testing
2 Scalability testing
Stress testing
2 Usability testing
® Application security testing
3. Why testing is difficult?
Software testing is probably the Most complex task in the
software development cycle. It often takes longer to test a software than
it does to vite the code. The problems discovered during the software
testing phase add more time onto the coding phase, resulting in further
delays in the product's release and so this vicious yele goes
9, Give the expansion of SQA,
SQA- Software Quality Assurance
19, Define Path,
Path is a sequence of statements Starting at an entry, junction or
decision and ending at another, or Possibly the same junction or decision
oran exit point,
11, How error differs from a bug?
Usually an "error" refers to some bit of
program. it may not conform to the language
tuntime error (ex: division by zero). A "bug"
programmer which causes the program to act
was not designed to act.
12. Give any two importances of decision tables,
°
illegal code in your
grammar, or it might be a
is a mistake made by the
in a manner for which it
Decision tables, especially when coupled with the use of
adomain-specific language, allow developers and policy
experts to work from the same information, the decision tables
themselves,
Decision tables have proven to be easier to understand and
review than code, and have been used extensively and
Successfully to produce specifications for complex systems. SECTION BS « 5=25 markyy
Answer any FI
! questions
All questions carry equal marks
13. How to maintain the quality in software?
e In production of consumer goods and other prod,
manufncturing stage is subjected to quality contro} iy Very
from component to final stage, Ml testing
+ If flaws are discovered at any stage, the produ
discarded or eyeled back for rework and coment Sither
¢ Productivity is measured by the sum Of the eo:
material, the rework, and the di
cost of quality assurance and tes
MS Of the }
Sand they!
isearded component
ing,
© There is a tmdeofl between quality assurance com
manufacturing costs: ficient time is not spent in i
assurance, the rejection rate will be high and so will be
cost. If inspection is good and all errors are ¢
occur, inspection costs will dominate, and apai
will suffer.
quality
the net
© Testing and Quality assurance costs for ‘manu
can be as low as 2% in consumer products or
products such as space-ships, nuclear reactor:
factured' items
high as 80% in *
ae f and aircraft,
where failures threaten life. Whereas the manufacturing cost of
software is trivial.
© The biggest part of software cost is the cost of bugs: the cost of
detecting them, the cost of correcting them, the cost of 16
designing tests that discover them, and the cost of running
those tests.
© For software, quality and productivity are indistinguishable
because the cost of a software copy is trivial.
14, Explain the technique of creating design style.
15, What is meant path instrumentation?
The outcome of a test is what we expect to happen as a result of the
test. Path instrumentation is what we have to do to confirm that the outcome
was achieved by the intended path.
Co-incidental Correctness
‘When expected and actual outcomes match,
© Necessary conditions for test to pass are met.
© Conditions met are probably not sufficient (the expected outcome
may be achieved due to a wrong reason) 4g Gener™
he types
gated Serre
16.
1 strategy / Path Instrumentation Methods
methods include:
of instrumentation n
sive Trace Program
‘An interpretive trace program is one that executes every statement
in order and records the intermediate values of all calculations, the
statement labels traversed ete.
ted routine under a trace, then we have all the
information we need to confirm the outcome and, furthermore, to
confirm that it was achieved by the intended path.
¢ with traces is that they give us far more information
than we need. In fact, the typical trace program provides so much
information that confirming the path from its massive output dump
jnvolves more work than simulating the computer by hand to
confirm the path.
Explain the concept of path testing,
n to a family of test techniques based
on judiciously selecting a set of test paths through the program.
I the set of paths are properly chosen then we have achieved some
measure of test thoroughness. For example, pick enough paths to
‘assure that every source statement has been executed at least once.
Idest_ of all structural test
if we run the test
‘The troubl
Path Testing is the name giver
Path testing techniques are the ol
techniques.
Path testing is most applicable to new software for unit
a structural technique.
testing. It is
It requires complete knowledge of the programs structure.
en used by programmers to unittest their own code,
he size of
Itis most oft
“The effectiveness of path testing rapidly deteriorates as 1
the software aggregate under test increases. 17. Give the importance of domain testing, a
© Domain: In mathematics, domain is a set of possible values of
independent variable or the variables of a function, ice
© Programs as input data classifiers: domain testing attempts
determine whether the classification is correct or not. °
Domain testing can be based on specifications or equivalent
implementation information.
> If domain testing is based on specifications, it is a functional test
technique.
‘2 If domain testing is based implementation details, it is a structural
test technique.
«For example, you're doing domain testing when you check extreme
values of an input variable,
All inputs to a program can be considered as if they are numbers.
For example, a character string can be treated as a number by concatenating
bits and looking at them as if they were a binary integer. This is the view in
domain testing, which is why this strategy has a mathematical flavor.
48. Explain the concept of structural metrics.
MeCabe’s Cyclomatic Complexity
+ Determines the logical complexity of a graph
— typically the graph is a flow graph of a function or
procedure
— — Itcan also be a graphical representation of an FSM.
= Independent path: any path that introduces at least one
new set of statements or a new condition; must move along
at least one edge that has not been traversed before.
Basis Set: a set of independent paths
Example: set of independent paths which comprise a basis
following flow graph:
set for the pst university Question Papers with Answers AS
patil: Lf
pati oot
+ a,b, & £
patrt:a Bier Boes £
ptt: & BG BOE
Alternate methods to calculate V(G):
_ V(G)=#of_predicate_nodes + 1
_ V(G)=4of edges ~ #of nodes +2
Note: in previous graph node ‘a’ has an out degree of 3, thus it
counts as 2 predicate nodes.
‘The previous graph could also have been drawn as:
+A predicate node is a node in the graph with 2 or more outgoing
ares,
«In the general case, for @ collection of C control graphs with k
connected components, the complexity is equal to the summation of
their complexities. That is
V(G)= 2G)
Information Flow Metric
* By Henry and Kafura:
— attempts to measure the
measuring the flow of information from on
another in terms of fan-ins and fan-outs.
— fancin: number of local flows into @ procedure plus the
‘number of global structures read by the procedure.
* fan-out: number of local flow from a procedure plus the number of
global structures updated by the procedure.
complexity of the code by
e procedure to
c AT
19.
20.
Flows represent:
the information flow into a procedure via the ar
lists and Samet
— Flows from the procedure due to return values of funeti
calls. i
Thus, the complexity of the procedure, p, is given by
Cp = (fan-in x fan-out)?
How decision tables can be used for logic testing?
‘The first task is to identify a suitable function or subsystem Which
reacts according to a combination of inputs or events. The system
should not contain too many inputs, otherwise the number of
combinations will become unmanageal le. Tt is better to deal with
large numbers of conditions by dividing them into subsets and
dealing with the subsets one at a time. Once you have identified the
aspects that need to be combined, then you put them into a table
listing all the combinations of true and false for each of the aspects,
SECTION C (3 x 10= 30 marks)
Answer any THREE questions
All questions carry equal marks
20. What is Bug? Discuss its types.
‘Asoftware bugis an error, flaw, mistake, failure, or fault in a
computer program or system that produces an incorrect or unexpected result,
or causes it to behave in unintended ways. The major categories are:
(1) Requirements, Features and Functionality Bugs
(2) Structural Bugs
(3) Data Bugs
(4) Coding Bugs
(5) Interface, Integration and System Bugs
(6) Test and Test Design Bugs.
Requirements, features and functionality bugs
The various categories in Requirements, Features and Functionality bugs
include:
e Requirements and Specifications Bugs
e Feature Bugs
e Feature Interaction Bugs ivertily, Question Papers with Answer
At
remount and Speelfientiony Rugs:
joa" selfieath
K equrenenls ant eciicont developed fiom them enn be
|e incomplete ambignots, OF nell-contidletory, They ean be
rood or impossible (und
nigunders ind,
ications that don't have flaw in them may chanpe while the
‘tho sper thief
The features are added, movified and deleted,
signi i POE
des
jentare BUR
gpecification problems usually create corresponding, feature problems.
A feu
purpos
wrong, feat
Removing, the features might complicate the software, consume more
and foster more bugs.
ature can be wrong, missing, oF superfluous (serving no useful
). A missing, Feature oF case is easier fo detect and corsect. A
sre could have deep design implications,
reso
-e Interaction Bugs
correct, clear, implementable and testable feature
lated features, The features of each
Features usually come in groups oF 1
within the group are usually well
group and the interaction of features
tested.
11, Diseuss on transact
Got the Transactions Flows
@ Complicated systems that process a Jot of different, complicated
transactions should have explicit representations of the transactions
flows, or the equivalent.
1 flow testing techniques,
© Transaction flows are like control flow graphs, and consequently
we should expect to have them in increasing levels of detail.
© The system's design documentation should contain an overview
section that details the main transaction flows.
© Detailed transaction flows are a mandatory pre requisite to the
rational design ofa system's functional test.
Inspections, Reviews and Walldhroughs
Start From Preliminary Design
|. Conducting Walkthroughs
© Discuss enough ‘Transaction Types (98% Transactions)
© User needs and functional terms (Design independent)
.
Traceability to requirements. 2, Design Testsfor C1 + C2 coverage
3, Additional Coverage (> C1+C2)
Paths with loops, extreme values, domain boundaries
4, Design Test cases for Tr. Splits and mergers
5, Publish Selected Test Paths early
6, Buyer’s Acceptance — functional and acceptance tests
Path Selection
° ve Me i
ee ee
e Select a covering set of paths based on functionally sensible
transactions as you would for control flow graphs.
© Try to find the most tortuous, longest, strangest path from the ent
to the exit of the transaction flow. a
Path Sensitization
e Most of the normal paths are very easy to sensitize-80% - 95%
transaction flow coverage (c1+c2) is usually easy to achieve,
e The remaining small percentage is often very difficult,
© Sensitization is the act of defining the transaction. If there are
sensitization problems on the easy paths, then bet on either a bug in
transaction flows or a design bug.
Path Instrumentation
Instrumentation plays a bigger role in transaction flow testing than
in unit path testing.
The information of the path taken for a given transaction must be
kept with that transaction and can be recorded by a central
transaction dispatcher or by the individual processing modules.
e Insome systems, such traces are provided by the operating systems
or arunning log.
22. How data flow testing strategies can be strengthened?
The structural test strategies discussed below are based on ee
program's control flowgraphs. They differ in the extent to which er
et,
uses and/or computational uses of variables are included in the test set 7°
ing order of their
Various types of data flow testing strategies in decreas!
effectiveness are
1. All - du Paths (ADUP)
2. All Uses Strategy (AU)
3. All p-uses/some c-uses strategy (APU+C) ry
py univers» Question Papers with Answer
Al0
4 All c-uses/some p-uses strategy (ACU+P)
_ All Definitions Strategy (AD)
¢all Predicate Uses (APU), All Computational Uses (ACU) Strategies
33. with an example, show how syntax testing is done,
Syntax Testing in Software Testing means it is widely used
sfiware testing term. Itis done in White Box Testing by using some tools or
‘manually depending on the nature of the Project. As we know, Syntax
esting is used in White Box Testing and hence it is obviously done by
developers.
Not in all the situations, it can be performed by developers, it can
also be done by the testers. Skilled testers mean white box testers,
As developers do this testing, they should be responsible for
running a syntax check before releasing their code to QA team.
In this testing, we test the syntax of the programming languages. As the
syntax of the every programming language is very different so is the criteria
for doing Syntax Testing on these programming languages.
Syntax Testing in Software Testing Example —php language
Given below is the cxample of Syntax Testing, which explains what
syntax testing is and what we should look for while testing it.
For example, let us assume we are doing the Syntax Testing of php
language. Then here we check whether the syntax is proper or not by
checking the starting and ending tag syntax of php language. As you know
starting tag of php is <2php and ending tag is ?>. So in this case we check
whether the starting tag () is also OK or not.
So, this is the Syntax Testing of php language has done by
developers and testers. And in the same way we can test the Syntax of Asp
language also which is given below.
Swntax Testing Example — Asp language
In the above example, you can see the Syntax Testing of php
language now we move towards Asp means how to test the Syntax of the
Sp language,
' As we know Starting tag of Asp is
: here we can test whether the starting and ending ag Syntax of Asp is OK
Tol. So this is the Syntax Testing done by us on ASP language. An Software Testing
24, Discuss the following:
(a) Transaction Testing (b) State Testing.
(a) Transaction Testing
Transaction testing generally refers to the testing of individual loans
and is also known as account testing, account sampling, or transaction-leve]
testing. Transaction testing is generally performed as part of each full scope
cxamination of a bank engaged in credit card lending and is sometimes
incorporated into target examinations or visitations when helpful in
analyzing the areas slated for review. According to the Expanded Guidance
for Evaluating Subprime Lending Programs, transaction testing should be
completed at each regularly-scheduled examination of banks engaged in
subprime lending. Transaction testing is one of the best techniques to
unearth the true quality of card portfolios and loan administration practices,
Reasons for Conducting Transaction Testing
‘Transaction testing is used to determine whether:
* Individual loans adhere to policy, underwriting, risk selection, and pricing
standards.
° Management, board, and regulatory reports are accurate and timely.
Loan accounting and servicing meet appropriate standards, including those
for account management.
* Key risk controls and control processes are adequate and functioning as
intended. Some examinations have revealed that even when written policies
and procedures appear satisfactory, system settings or other devices might be
allowing activity that is contrary to the policies and/or that does not meet
applicable guidance and laws.
© Roll-rates and other loss forecasting methods used to determine that the
Joss allowance levels are accurate and reliable.
» Lending practices exist that may appear unsafe, unsound, abusive, or
unfair. y
versity Question Papers with Answers
| past us
University of Madras
B.Sc. (CS)
| goveber 2015 50419/SAZ6CISEESB/SEUGG
| ine: Tee hows Maximum: 75 marks
SECTION A- (10x2=20 marks)
Answer any TEN questions.
All questions carry equal marks,
4, Define Quality in software.
requirements ifit is to be considered to be ofa good quality.
2, What do you mean by Bug?
change our notion of what a bug is,
4, What are the various testing styles?
» Functionality testing
Forced error testing
© Compatibility testing
© Performance testing
© Scalability testing
¢ Stress testing
© Usability testing
| © Application security testing
4, Define Flow graphs.
A flow graph Gis defined as a finite set N of nodes a
finite set E of directed edges. An edge (i,
directed from itoj, connects nodes nj an
vite G= (N,B) to denote a flow graph G with nodes in Nand
edges in E,
5. What is called Transaction?
.) in E, with an arrow
dyin N, We often
Al2
A Sofware must conform to explicit and implicit
Bugs are more insidious (deceiving but harmful) than ever
we expect them to be. An unexpected test result may lead us to
ind a
© A transaction is a unit of work seen from a system user's point of
view, 9.
ue.
A transaction consists of a sequence of operations, Some of which
are performed by a system, persons or devices that are outside the
system.
Transaction begins with Birth — that is they are created as a result
of some external act.
Mention the various testing strategies.
Top-Down Testing
Bottom-Up Testing
Thread Testing
Stress Testing
Back- to Back Testing
Define Path.
Path is a sequence of statements starting at an entry,
junction or decision and ending at another, or possibly the same
junction or decision or an exit point.
Write note on syntax testing.
System inputs must be validated. Internal and external
inputs must conform to formats:
a. Textual format of data input from users.
b. File formats.
c. Database schemata.
What is a path expression?
The Path expression is a representation of a set of all
possible paths between two nodes.
List out the various formats of testing.
Performance testing
Security testing
Exploratory Testing
Mutation Testing
Smoke Tests.
‘What are the contents in decision table?
Define State Graph.
State Graphs are very useful for describing the behaviors
of individual objects over a full set of use cases that affect those
objects. State Graph is a combination of states and transitions. eo
ay Question Papers wilh Answers
SHCTION 1h (5 + 5#26 marta)
Answer any FIVE questions,
All questions carry equal marks
mensLilf
and contrast the functions of texting ant debuggsng,
13. compare
ais willy kno
uses predefined
yredictable
ions,
eondit
a hres an as
proce
utc
ing can and should be
designed and
planned
sehoduled.
‘Tes
error or apparent correclnes
rating # demonstration of
Debugging,
Debugging, starts from prossibly
unknown initial conditions and the
end cannot he predicted except
statistically,
duration — of
be
Procedure — and
debugging cannot
constrain
i proves a programme's
fie. :
Festing, as executed, should
srive to be predictable, dull,
rigid and
constrained,
inhuman.
IggIng the programmer's
vindication (Justificatio
| Debugging — dema
leaps, experimentation and
freedom.
Testing can be done without
‘much design knowledge.
Debugging is impossible without
detailed design knowledge.
Testing can often be done by
an outsider.
Much of test execution and
design can be automated.
St
‘Automated debugging is still a
Debugging must be done by af
insider.
dream.
14, Diseu
The major categories are:
(1) Requirements,
jef about types of bugs.
Features and Functionality Bugs
| (2) Structural Bugs
(3) Data Bugs
(4) Coding Bugs
(5) Interface, Integration and System Bugs
Fy (6) Test and Test Design Bugs.
_ “uirements, features and functionality bugs
The various categories in Requirements, Features and Functionality
Sues include:
© Requirements and Specifications Bugs ai Soft Testing
e Feature Bugs
e Feature Interaction Bugs
Requirements and Specifications Bugs
«Requirements and specifications developed from them can he
incomplete ambiguous, or self-contradictory. They can be
misunderstood or impossible to understand.
«The specifications that don't have flaws in them may change while the
design is in progress. The features are added, modified and deleted,
Feature Bugs
e — Specification problems usually create corresponding feature problems,
© A feature can be wrong, missing, or superfluous (serving no useful
purpose). A missing feature or case is easier to detect and correct. A
wrong feature could have deep design implications.
iB ign imp
e Removing the features might complicate the software, consume more
resources, and foster more bugs.
Feature Interaction Bugs
e Providing correct, clear, implementable and testable feature
specifications is not enough.
Features usually come in groups or as related features. The features of,
each group and the interaction of features within the group are usually
well tested.
15. Describe about transaction system properties.
16. Write short notes on Domain Testing.
Domain testing can be used to perform functional testing and also,
structural testing. An entire domain testing effort focuses on identifying a set
of domains in a program and appropriate set of input values corresponding to
each domain so identified. Following this, input values will be supplied and
the behavior of the program is checked to ensure whether it is as expected. It
is important to notice that domain testing will be effective only with a
domains which are linear, complete, systematic, orthogonal, consistently
closed, connected, and convex. Domain testing will be ineffective with o y
domains that have ill-defined boundaries which are non-linear, wich oe
ambiguities and contradictions, and have problems related to vow a
close Without simplification and rectifying problems related ae pals
closure, domain testing on uely domains would result in nacht ee
since it is not possible to choose appropriate input values. BY "S04 and
eanae es such as Boundary Value Analysis ae fewer
Equivalent Pastiions (EP) are devised which would allow (0 oro peo
S to carry out effective testing, In addition, there js ane
es AI6
and coordinate tran; i
formations in ord
sing, appropriate input domains, cre
in
el In mathematics, d
4 in: In mathematics, domain is a se ‘1
¢ Dammains Tn mat 7 nalicss domain is a set of possible values of an
| independent variable or the Variables ofa function,
|, Programs as input dala classifiers: domain testing attempts to
determine whether the classification is correct or not.
Domain testing can be based on specifications or equivalent
implementation information.
If domain testing is based on specifications, it is a functional test
technique.
¢ Ifdomain testing is based implementation details, it is a structural
| test technique.
‘For example, you're doing domain testing when you check extreme
values of an input variable.
All inputs to a program can be considered as if they are mumbers.
For example, a character string can be treated as a number by concatenating
| fits and looking al them as if they were a binary integer. This is the view in
ing, which is why this strategy has a mathematical flavor.
brief about path expression and path products.
Path Expressions
Consider a pair of nodes in a graph and the set of paths between
those nodes.
Denote that set of paths by Upper case letter such as X,Y. From
Figure 5.lc, the members of the path set can be listed as follows:
ac, abe, abe, abbbe, abbbbc...
Alternatively, the same set of paths can be denoted by :
actabe+abbetabbbe+abbbbe- .
‘The + sign is understood to mean or" between the two nodes of
interest, paths ac, or abe, or abbe, and so on can be taken.
Any expression that consists of path names and "OR"s and which
denotes a set of paths between two nodes is called a "Path
Expression."
Path Products
The name of a path that consists of two successive path segments is
conveniently expressed by the ‘concatenation or Path Product of the
‘segment names.
For example, if X and Y are defined as X=abede, Y=fehij,then the
path corresponding to X followed by Y is denoted by AIT Software Testing
a
XY=abcdefghij
© Similarly, -
YX=fghijabcde
aX=aabede
Xa=abcdea
XaX=abcdeaabede
e IfX and Y represent sets of paths or path expressions, their Product
represents the set of paths that can be obtained by following every
element of X by any element of Y in all possible ways, For
example,
X=abe + def + ghi
Y=uw+z
Then,
XY = abcuvw + defuvw + ghiuvw + abez + defz + ghiz
e Ifa link or segment name is repeated, that fact is denoted by an
exponent, The exponent's value denotes the number of repetitions:
al = a; a? = aa; a? = aaa; an = aaa... n times.
Similarly, if
X= abcde
then
X!= abcde
X? = abedeabede = (abcde)?
X? = abedeabcdeabede = (abcde)2abede = abede(abede)?=
(abede)?
© The path product is not commutative (that is XY!=YX).
© The path product is Associative.
RULE 1: A(BC)=(AB)C=ABC
where A,B,C are path names, set of | path names or path expressions.
° The zeroth power of a link name, path product, or path expression is
also needed for completeness. It is denoted by the numeral "I" and
denotes the "path" whose length is zero - that is, the path that
doesn't have any links,
ad=1
Xx0=1 y
past university Question Papers with Answers AMS
sg iseuss
°
about logic based test
‘The functional requirements of many programs can be specified by
decision tables, which provide a useful basis for program and test
design.
Consistency and completeness can be analyzed by using boolean
algebra, which can also be used as a basis for test design. Boolean
algebra is trivialized by using Kamnaugh-Veitch charts.
"Logic" is one of the most often used words in programmers’
vocabularies but remains as one of their Jeast used techniques.
Boolean algebra is to logic as arithmetic is to mathematics. Without
it, the tester or programmer is cut off from many test and design
techniques and tools that incorporate those techniques.
Logic has been, for several decades, the primary tool of hardware
logic designers.
Many test methods developed for hardware logic can be adapted to
software logic testing, Because hardware testing automation is 10 to
15 years ahead of software testing automation, hardware testing
methods and its associated theory are a fertile ground for software
testing methods,
As programming and test techniques have improved, the bugs have
shifted closer to the process front end, to requirements and their
specifications. These bugs range from 8% to 30% of the total and
because they're first-in and last-out, they're the costliest of all.
‘The trouble with specifications is that they're hard to express.
Boolean algebra (also known as the sentential calculus) is the most
basic of all logic systems.
Higher-order logic systems are needed and used for formal
specifications.
Much of logical analysis can be and is embedded in tools. But these
tools incorporate methods to simplify, transform, and check
specifications, and the methods are to a large extent based on
boolean algebra.
20. Write notes on Transition testing.
| Get the Transactions Flows
Complicated systems that process a lot of different, complicated
transactions should have explicit representations of the transactions
flows, or the equivalent.
Transaction flows are like control flow graphs, and consequently
We should expect to have them in increasing levels of detail. Softyare
ny
's design documentation should cont
s Hi AN Overyiey
ion that details the main transaction flows,
© Detailed transaction Hows are a mandatory pre requisite to the
rational design of a sys functional test,
and Wallthroughs
Inspections, Review:
Start From Preliminary De
1. Conducting Walkthroughs
gg
° enough Transuetion Types (98% Transactions)
© User needs and functional terms (Design independeny
© Traceability to requirements,
ign Tests for C1 + C2 coverage
3. Additional Coverage (> CH+€2)
© Paths with loops, cxtreme values, domain boundaries
4, Design Test cases for Tr, Splits and mergers
5. Publish Selected Test Paths early
6. Buyer’s Acceptance ~ functional and acceptance ests
Path Selection
® Select a set of covering paths (cl-+c2) using the analogous criteria
you used for structural path testing.
© Select a covering set of paths based on functionally sensible
transactions as you would for control flow graphs.
© Try to find the most tortuous, longest, strangest path from the entry
to the exit of the trans
Path Sensi
© Most of the normal paths are very casy to sensitize-80% - 95%
transaction flow coverage (c1-+c2) is usually casy to achieve.
© The remaining small percentage is often very difficult,
°
tization is the act of defining the transaction. If there are
‘ation problems on the easy paths, then bet on either a bug in
transaction flows or a design bug,
Path Instrumentation
¢ Instrumentation plays a bigger role in transaction flow testing than
in unit path testing,
© The information of the path taken for a given transaction must e
kept with that transaction and can be recorded by a central
transaction dispatcher or by the individual processing modules. SECTION CG ~10=30 marks)
Answer any THREE questions
All questions carry equal marks
gp. Write an overview about the following (a) Mode for Test
Q sting.
tudes three models:
«< a model of testing process. It inch
nd a model of the
A model of the environment, a model of the program 2
expected bugs.
Environment
and software required to
‘A Program's environment is the hardware i
a SF The environment may, include
communication lines, other systems, terminals and operators.
The environment also includes all programs that interact with and
are used to create the program under test \s, linkage editor, joader,
compiler, utility routines.
= such as 0}
Because the hardware and fi
blame the environment for bugs.
irmware are stable, it js not smart (0
Program
too complicated
Most programs are 100 sified in 0
concept of the program js to be simplitie! jor, we MAY
of the rogram does ot explain te UnexPEE behavior,
modify that model to include more facts
may have to modify the progran A2l
ftware Tes
Bugs
Bugs are more insidious (deceivin;
them to be. An unexpected test result may lead us to change our Noti
what a bug is and our model of bugs. Some optimistic neuen ea of
programmers or testers have about bugs are usually unable to test ef
and unable to justify the dirty tests most pro;
ffectively
: ctively
Optimistic Notions about Bugs
Benign Bug Hypothesis: The belief that bugs are nice, tae ma
logical. (Benign: Not Dangerous)
Bug Locality Hypothesis: The belief that a bug discovered within A
component affects only that component's behavior.
Control Bug Dominance: The belief that error in the contol
structures (if, switch ete) of programs dominate the bugs.
Code / Data Sep.
of code and data.
Lingua Salvatore Est.:
semantics (c.g. Structured Coding,
Corrections Abide:
remains corrected.
but harmful) than we expest
aration: The belief that bugs Tespect the separation
The belief that the language syntax and
, Strong typing, etc) eliminates most bugs.
The mistaken belief that a corrected bug
Silver Bullets: The mistaken belief that X (Language, Design
method, representation, environment) grants immunity from bugs.
Sadism Suffices: The common belief (especially by independent
tester) that a sadistic streak, low cunning, and intuition are sufficient to
climinate most bugs. Tough bugs need methodology and techniques.
Angelic Testers: The beliefs that testers are good at test design than
the programmers are at code design.
Tests
Tests are formal procedures, Inputs must be prepared, eee
should predict, tests should be documented, commands need to be execute:
and results are to be observed. All these are subjected to errors.
Testing and Levels
We do three distinct kinds of testing on a typical software syste™
They are:
© Unit / Component Testing
© Unit Testing
© Integration Testing:
rey Question Papers: with Anwners
iv nivel
component Tel
nit he snallnt Wesley of ettvene tak can ts
nomblud, linked, loaded ets, A unit is usually the wore of ones
{consist of several hundred or fewer lines of oe,
a
“yy
“in Mm
hal ‘peat
It eating comprises the sot of bak patie by aii
pilor to jntepration Wustrated tito » larger system. This
niet
rn init lo
| Coline.
| & » Unit Teating > Irteygaion Sesing
| pebupeine
particular function or are rates. I is
posto ete of tefing, he developer canes ort eta nde
i the pour ele or unit of wks is working Sine Unit ti,
fan at he very ae evel i is ari oe, When he ont ofthe
t
Phin tenting, bs used to te
«J or a particular functionality id built.
init texting requiren detailed Knweruledge of the interral
| popram din ad code, i is generally perfirmed ty the payers aad
wi by ily done, as it requires well designed
| chitecture of application with tight wie,
Integration Texting
A proup of dependent components are tested together to ensure
Iheir quality of their intepyation unit,
‘The objectives id to take unit tested components and build a
program structure that has been dictated by software design.
The focus of integration tenting is to uncover errors in:
© Design and construction of woftware architecture,
© Integrated functions or operations at sub-ryraern level
* Interfaces and interactions between ther.
* Resource integration and/or environment integration
System Texting
Wietieg men tes ing ae on testing the complete systems with
System het eee and nee - a
ing involves two kinds of activities:
© Integration texting and
* Acceptance testing
i Rar ve f if
Ter
' ¥ Wires
} a ‘|
i
: t 1 |
a}
il
su that
Which mo
the onter in which
ars execution of Finstion tt
be measured in terms of humans
0 seal of one to ten
esthetically (gently); a misspelled
is dehumanizing, Eg
Tegal) transactions.
ed invalid
n itself but
transaction ite
s lost
Go the wrong transactions
to another account
‘ s oF too fee transaetb®
xd of sporadic infrequent) oF
and
occu a
e corruption of the database °° ig
ation is 8°
idera
the corruption is not easily
Shutting the system down.
Catastrophic: The dec’
the system fails.
discovered. Serious consi
pecs?
s taken out of our hans
to shut dow
ive) Quetig
> What cay
gelloven though jy ita]
net HAL ei
tng
1H deta ayy
Coverag
My
Mainly wait
Uw an Tea ga
one company gym
(jub-outne)
subroutines, it
+ Un reality,
Stubs- may be gui
auibroutin,
To achiev Clacdey
+ Pre ne
sub a
+ Senin eg
+ Sele uh
cons
fw Code
Do Path Tests frGl Coot
Use the proces)
using a mecha
A path ‘ockelunnet
When a bug oot
Maintenance
Path testing ish)
Use the procedi
but without wsill
Select paths wh
Never anil mitt
in maintenam
Sofware
Application” | ersity Question Papers with Answers A24
9st
! igus: What can ‘be worse than a failed system? One that corrupts other
jet ough it doesnot fl in isl; that erodes the social physica
ee nent that melts nuclear reactors and starts war.
ean in det about appction of path esting
21 BY on, Coverage, and Paths in Called Components
fc ss ;
10 inly used in Unt testing, espeielly new software.
In an Idealistic bottom-up integration test process — integrating
‘one component at a time. Use stubs for lower level component
(Gubstoutines), test interfaces and then replace stubs by real
subroutines.
«In reality, integration proceeds in associated blocks of components.
Stubs may be avoided. Need to think abdut paths inside the
| subroutine.
To achieve CI or C2 coverage:
| + Predicate interpretation may require us to treat a
subroutine as an in-line-code.
| + Sensitization becomes more difficult.
+ Selected path may be unachievable as the called
| components’ processing may block it.
| New Code
+ Do Path Tests for Cl + C2 coverage
+ Use the procedure similar to the idealistic bottom-up integration testing,
using a mechanized test suite,
+ Apath blocked o not achieved could mean a bug.
+ When a bug occurs the path may be blocked.
Maintenance
* Path testing is applied first to the modified component.
* Use the procedure similar to the idealistic bottom-up integration testing,
but without using stubs.
Select paths to achieve C2 over the changed code.
Newer and more effective strategies could emerge to provide coverage
M maintenance phase.
Rehosting
Path testing wi i
itive with Cl + C2 coverage is a powerful tool for rehosting old
Software i
Ware is rehosted as it’s no more cost effecti
“lication on A fective to support the a
A25 Soft
«Use path testing in conjunction with automatic op 8
structural test generators. Semiautomat c
Process of path testing during rehosting
+ A translator from the old to the new environment is creat
Rehosting process is to catch bugs in the translator soften and tested,
+ A complete Cl + C2 coverage path test suite is created
software, Tests are run in the old environment, The ute forthe old
the specifications for the rehosted software. ‘Mes become
+ Another translator may be needed to adapt the tests & out
new environment.
+ The cost of the process is high, but it avoids the risks as.
rewriting the code
+ Once it runs on new environment, it can be optimi;
ia , tH can be optimized or enhanced fop
+ Functionalities (which were not possible in the od environment)
22. Describe about dataflow testing strategies, :
a Various types of data flow testing strategies in decreasing order of their
effectiveness are
1. All - du Paths (ADUP)
2. All Uses Strategy (AU)
3. All p-uses/some c-uses strategy (APU+C)
4, All c-uses/some p-uses strategy (ACU+P)
5. All Definitions Strategy (AD)
6. All Predicate Uses (APU), All Computational Uses (ACU) Strategies
1, All - du Paths (ADUP): The all-du-paths (ADUP) strategy is the
strongest data-flow testing strategy discussed here. It requires that every du
path from every definition of every variable to every use of that definition be
exercised under some test.
For variable X and Y: (Pl. refer to figure 6.6 in page 80): Because
variables X and Y are used only on link (1,3), any test that starts at the entry
satisfies this criterion (for variables X and Y, but not for all variables as
required by the strategy).
For variable Z: The situation for variable Z (PI. refer to figure 6.7 in page
81) is more complicated because the variable is redefined in many places
For the definition on link (1,3) we must exercise paths that include spats
(1,3,4) and (1,3,5). The definition on link (4,5) is covered by any path
includes (5,6), such as subpath (1,3,4,5,6, ..). The (5,6) definition ren"
paths that include subpaths (5,6,7,4) and (5,6,7,8).
Comes to the
sociated with wee
mae
4h
iy
=
SESH
ees
Bae
iable V: Variable V (Pl refer to figure 6.8 in page 81): is defined
port ce on link (1,3). Because V has a predicate use at node 12 and the
ol eal path to the end must be forced for both directions at node 12, the
ibs” ths strategy for this variable requires that we exercise all loop-free
er paths and at least one path that includes the loop caused by (11,4)
ee «we must test paths that include both subpaths (3,4,5) and (3,5) even
vote either of these has V definitions. They must be included because
tho yovide alternate du paths to the V use on link (5,6). Although (7,4) is
ased in the test set for variable V, it will be included in the test set that
ot oe the predicate uses of array variable V() and U:
: ‘The all-du-paths strategy is a strong criterion, but it does not take as
y tests as it might seem at first because any one tesi simultaneously
ary the criterion for several definitions and uses of several different
