Question Paper Solution - e-Learning · project Examples: - The ratio of actual to expected system...

Software Testing 06IS81

Dept.Of ISE, SJBIT 1

Question Paper Solution

UNIT 1

BASICS OF SOFTWARE TESTING – 1

1 a) Define the following May/June 2010

i) Errors ii) Faults iii) Failure iv) Bug

Soln:Humans make errors in their thoughts, actions, and in the products that might result

from their actions. Errors occur in the process of writing a program.

II) A programmer makes an error (mistake), which results in a defect (fault, bug) in

the software source code. If this defect is executed, in certain situations the system will

produce wrong results, causing a failure.

III) A failure occurs when a faulty piece of code is executed leading to incorrect state

that f propagates to the program’s output.

IV) software defects are caused by coding errors. One common source of expensive

defects is caused by requirement gaps.

b) Discuss Attributes associated with Software Quality?

Soln:

Software Quality Attributes

- Static Attributes:

i) Maintainability and its Sub-characteristics:

In software engineering, the ease with which a software product can be modified in order to



correct defects meet new requirements make future maintenance easier, or cope with a

changed environment.

These activities are known as software maintenance.

A set of attributes that bear on the effort needed to make specified modifications are:

i) Analyzability: Attributes of software that bear on the effort needed for diagnosis of

deficiencies or causes of failures, or for identification of parts to be modified

ii)Changeability: Attributes of software that bear on the effort needed for modification, fault

removal or for environmental change

iii)Stability: Attributes of software that bear on the risk of unexpected effect of modifications

iv) Testability: Attributes of software that bear on the effort needed for alidating the modified

software. The degree to which a system or component facilitates the establishment of test

criteria and the performance of tests to determine whether those criteria are met .

Static Testability Ex: Software Complexity

Dynamic Testability Ex: Test Coverage Criteria

Software Quality Attributes:

- Dynamic Attributes:

v)Completeness: The availability of all the features listed in the requirements or in the user

manual.

vi) Consistency: adherence to a common set of conventions and assumptions.

vii) Compliance: Attributes of software that make the software adhere to application

related standards or conventions or regulations in laws and similar prescriptions



viii) Conformance : Attributes of software that make the software adhere to standards or

conventions relating to portability.

ix) Usability: The ease with which an application can be used. Usability testing also refers

to testing of a product by its potential users

x) Understandability: Attributes of software that bear on the users' effort for recognizing the

logical concept and its applicability

xi) Learnability: Attributes of software that bear on the users' effort for learning its application

xii) Operability : Attributes of software that bear on the users' effort for operation and

operation control

xiii)Performance: The time the application takes to perform a requested task.Performance is

considered as a nonfunctional requirement.

xiv)Time behavior: Attributes of software that bear on response and processing times and on

throughput rates in performances its function

xv) Resource behavior: Attributes of software that bear on the amount of resource used and

the duration of such use in performing its function

xvi) Reliability: Software Reliability is the probability of failure-free operation of software over a

given time interval and under given conditions

xvii)Maturity: Attributes of software that bear on the frequency of failure by faults in the

software.

xviii) Fault tolerance: Attributes of software that bear on its ability to maintain a specified level

of performance in case of software faults or of infringement of its specified interface.

xix)Recoverability: Attributes of software that bear on the capability to re- establish its level of



performance and recover the data directly affected in case of a failure and on the time and

effort needed for it.

For example, the Transmission Control Protocol (TCP) is designed to allow reliable two-way

communication in a packet-switched network, even in the presence of

communications links which are imperfect or overloaded. It does this by requiring the

endpoints of the communication to expect packet loss, duplication, reordering and

corruption, so that these conditions do not damage data integrity, and only reduce

throughput by a proportional amount.

Recovery from errors in fault-tolerant systems can be characterized as either roll-forward or

roll-back. When the system detects that it has made an error, roll-forward recovery takes

the system state at that time and corrects it, to be able to move forward. Roll-back recovery

reverts the system state back to some earlier, correct version, for example using check

pointing, and moves forward from there.

c) What is a Test Metric? List Various Test Metrics ?and Explain any two? July 2010

Soln:

Quantitative measurement determining the extent to which a software process, product or

project possesses a certain attribute (used for tracking purposes).

Goal for the metric is to quantify the progress of the product toward a specified quality

objective.

Organizational Metrics

Project Metrics

Process Metrics

Product Metrics



Organizational Metric:

Metrics at organizational level are useful in project planning and management.

Examples:

- Defects per thousand lines of code (defects/KLOC)

- Testing cost per KLOC

- Actual schedule of system testing

- Delivery schedule slippage

Project Metrics

Project Metrics relates to a specific project. Useful in the monitoring and control of the

project

Examples:

- The ratio of actual to expected system test effort

- Ratio of number of successful tests to the total number of tests.

UNIT 1


1a) How do you measure Software Quality? Discuss Correctness versus Reliability Pertaining to

Programs? Dec/Jan 2010

Soln:

The correctness will be established via requirement specification and the program text to prove

that software is behaving as expected.



The reliability is the probability of the successful execution of program on randomly selected

elements from its input domain.

Though correctness of a program is desirable, it is almost never the objective of testing.

To establish correctness via testing would imply testing a program on all elements in the

input domain. In most cases that are encountered in practice, this is impossible to accomplish.

Thus correctness is established via mathematical proofs of programs.

While correctness attempts to establish that the program is error free, testing attempts to find if

there are any errors in it.Thus completeness of testing does not necessarily demonstrate that a

program is error

b) Discuss Various types of Metrics used in software testing and Relationship? Dec/Jan 2010

Soln:

Quantitative measurement determining the extent to which a software process, product or project

possesses a certain attribute (used for tracking purposes) Goal for the metric is to quantify the

progress of the product toward a specified quality Objective.


Project Metrics

Process Metrics

Product Metrics



Examples:







Project Metrics


project

Examples:



Process MetricsEvery project uses the process. The goal of Process Metrics to measure the goodness of

the process

Examples:

- The number of errors found in different testing phases

Product MetricsProduct metrics are useful in making decisions related to the product. For example should

the product be released to the client?

Examples:

- Cyclomatic complexity:

V(G) = E - N + 2p

V(G) is the complexity of the control flow graph. E is the edges, N nodes, p the

connected procedures

V(G) of the value 5 or less are preferred

Halstead metrics:

B = 7.6 E0.667S0.333



B represents the number of errors found during software development. S the program

size and E is the effort.

Hasltead Measures of Program

complexity and effort

Operation Count N1

Number of Operators in a Program

Operand Count N2

Number of Operands in a program

Unique Operators _1

Number of unique Operators in a Program

Unique Operands _2

Number of unique Operands in a program

Program Vocabulary _ _1 + _2

Program size N N1 + N2

Product Metrics : OO Software

Reliability: Probability of failure of a software product with respect to a given operational profile

in a given environment Defect Density: Number of defects per KLOC Defect Severity:

Distribution of defects by their level of severity.

Test Coverage: Fraction of Testable items

e.g. Basic blocks covered Cyclomatic Complexity: Measures complexity of a program based on

its CFG Weighted Methods per class: _nn=1Ci, Ci is the complexity of method i in the class

Class Coupling: Measures the number of classes to which a given class is coupled Response set:

Set of all methods that can be invoked directly or indirectly, when a message is sent to object O

Number of Children: Number of immediate descendents of a class in the class

UNIT 1




1 a) Explain Static & Dynamic Attributes? June 2011

Soln: -

Static Attributes:




changed environment


















manual.












operation control

xiii)Performance: The time the application takes to perform a requested task.

Performance is considered as a nonfunctional requirement.










software.












Recovery from Quantitative measurement determining the extent to which a software process,

product or project possesses a certain attribute (used for tracking purposes) Goal for the metric is

to quantify the progress of the product toward a specified quality Objectiveerrors in fault-

tolerant systems can be characterized as either roll-forward or roll-back. When the system

detects that it has made an error, roll-forward recovery takes the system state at that time

and corrects it, to be able to move forward. Roll-back recovery reverts the system state back

to some earlier, correct version, for example using check pointing, and moves forward from

there.

b) Briefly explain different types of Test Metrics? June 2011

Soln:




Project Metrics

Process Metrics

Product Metrics



Examples:





Project Metrics


project

Examples:



Process MetricsEvery project uses the process. The goal of Process Metrics to measure the goodness of



the process

Examples:

- The number of errors found in different testing phases

Product Metrics

Product metrics are useful in making decisions related to the product. For example should

the product be released to the client?

Examples:

- Cyclomatic complexity:

V(G) = E - N + 2p

V(G) is the complexity of the control flow graph. E is the edges, N

nodes, p the connected procedures

V(G) of the value 5 or less are preferred

Halstead metrics:

B = 7.6 E0.667S0.333

B represents the number of errors found during software development. S the program

size and E is the effort.

Hasltead Measures of Program

complexity and effort

Operation Count N1

Number of Operators in a Program

Operand Count N2

Number of Operands in a program

Unique Operators _1

Number of unique Operators in a Program

Unique Operands _2

Number of unique Operands in a program

Program Vocabulary _ _1 + _2

Program size N N1 + N2

Product Metrics : OO Software



Reliability: Probability of failure of a software product with respect to a given operational profile

in a given environment Defect Density: Number of defects per KLOC Defect Severity:

Distribution of defects by their level of severity.

Test Coverage: Fraction of Testable items

e.g. Basic blocks covered Cyclomatic Complexity: Measures complexity of a program based on

its CFG Weighted Methods per class: _nn=1Ci, Ci is the complexity of method i in the class

Class Coupling: Measures the number of classes to which a given class is coupled Response set:

Set of all methods that can be invoked directly or indirectly, when a message is sent to object O

Number of Children: Number of immediate descendents of a class in the class

C) What are Input Domain and program correctness? June 2011

Soln:

Input domain (Input space) is the set of all possible inputs to a program P is known as the input

domain or input space, of P.Using Requirement 1 above we find the input domain of max to be

the set of all pairs of integers where each element in the pair integers is in the range -32,768 till

32,767. Using Requirement 2 it is not possible to find the input domain for the sort program.The

correctness will be established via requirement specification and the program text to prove that

software is behaving as expected. The reliability is the probability of the successful execution of

program on randomly selected elements from its input domain.Though correctness of a program

is desirable, it is almost never the objective of testing.To establish correctness via testing would

imply testing a program on all elements in the input domain. In most cases that are encountered

in practice, this is impossible to accomplish. Thus correctness is established via mathematical

proofs of programs.



UNIT 1


1 a) Why is it difficult for tester to find all bugs in the system? Why might not be necessary for

the program to be completely free of defects before its delivered to customers?

10 Marks Dec/Jan 2011

Soln:

Humans make errors in their thoughts, actions, and in the products that might result from their

actions. Errors occur in the process of writing a program.

A programmer makes an error (mistake), which results in a defect (fault, bug) in the

software source code. If this defect is executed, in certain situations the system will

produce wrong results, causing a failure. Not all defects will necessarily result in failures.

For example, defects in dead code will never result in failures. A defect can turn into a failure

when the environment is changed. Examples of these changes in environment include the

software being run on a new hardware platform, alterations in source data or interacting with

different software. A single defect may result in a wide range of failure symptoms.

b) Define Software quality attributes?Distinguish between Static and Dynamic Attributes?

Soln:

Software quality is a multidimensional quantity and is measurable.

To do this, we need to divide and measure software quality in terms of quality attributes:

_ Static Quality Attributes

_ Dynamic Quality Attributes

- Static Attributes:






changed environment
















manual.














operation control

xiii)Performance: The time the application takes to perform a requested task. Performance is

considered as a nonfunctional requirement.








software.














Recovery from errors in fault-tolerant systems can be characterized as either roll-forward or

roll-back. When the system detects that it has made an error, roll-forward recovery takes

the system state at that time and corrects it, to be able to move forward. Roll-back recovery

reverts the system state back to some earlier, correct version, for example using check

pointing, and moves forward from there.

UNIT 2


2 a) Explain Testability & Verification? Jun 2010

Soln:-

Software quality is ensured by Verification and Validation

Verification : "Is the system correct to specification?"

• Confirmation by examination and through the provision of objective evidence that specified

requirements have been fulfilled



Validation : "Is this the right specification?"

• Confirmation by examination and through the provision of objective evidence that the

requirements for a specific intended use or application have been fulfilled.

b) What is Defect Management?List different activity and explain any Two? Jun 2010

Soln:

The defect management process is based on the following general principles:

The primary goal is to prevent defects. Where this is not possible or practical, the goals are to

both find the defect as quickly as possible and minimize the impact of the defect.The defect

management process should be risk driven -- i.e., strategies, priorities, and resources should be

based on the extent to which risk can be reduced. Defect measurement should be integrated into

the software development process and be used by the project team to improve the process. In

other words, the project staff, by doing their job, should capture information on defects at the

source. It should not be done after-the-fact by people unrelated to the project or system As much

as possible, the capture and analysis of the information should be automated. Defect information

should be used to improve the process. This, in fact, is the primary reason for gathering defect

information.

i)Defect Prevention: Implementation of techniques, methodology and standard processes to

reduce the risk of defects.

ii)Deliverable Baseline: Establishment of milestones where deliverables will be considered

complete and ready for further development work. When a deliverable is baselined, any further

changes are controlled. Errors in a deliverable are not considered defects until after the

deliverable is baselined.

iii)Defect Discovery: Identification and reporting of defects for development team

acknowledgment. A defect is only termed discovered when it has been documented and

acknowledged as a valid defect by the development team member(s) responsible for the

component(s) in error.



iv)Defect Resolution: Work by the development team to prioritize, schedule and fix a defect, and

document the resolution. This also includes notification back to the tester to ensure that the

resolution is verified.

v)Process Improvement: Identification and analysis of the process in which a defect originated to

identify ways to improve the process to prevent future occurrences of similar defects. Also the

validation process that should have identified the defect earlier is analyzed to determine ways to

strengthen that process.

vi)Management Reporting: Analysis and reporting of defect information to assist management

with risk management, process improvement and project management.

c) Explain Static Testing and Model based Testing and Checking? Jun 2010

Soln:

Static testing is a form of software testing where the software isn't actually used. This is in

contrast to dynamic testing. It is generally not detailed testing, but checks mainly for the sanity

of the code, algorithm, or document. It is primarily syntax checking of the code and/or manually

reviewing the code or document to find errors. This type of testing can be used by the developer

who wrote the code, in isolation. Code reviews, inspections and walkthroughs are also used.

Model-Based Testing refers to the acts of modeling and the generation of tests from a formal

model of application behavior.

Model Checking refers to a class of techniques that allow the validation of one or more

properties from a given model of an application.



UNIT 2

BASICS OF SOFTWARE TESTING-2

2a) Explain Software testing and Dynamic Testing over Fault model, test domain and Coverage?

Dec 2010

Soln:

Software Testing

_ Software Application does not degrade over time

_ Model based in testing uses mutation, state transition diagram

_ Test domain uses exhaustive set of test cases formed from data types

_ Test coverage: Complete testing is impossible

Hardware Testing

_ Hardware may fail over time

_ Built-in Self Test (BIST) internal monitoring mechanisms are installed to test the correct

functioning of a circuit.

_Fault model based test case generation at different levels- Transistor level, Gate level, circuit

level, function level

_ Test domain and test suite consists of a bit pattern and a set/ sequence of bit patterns

_ Test coverage: Complete testing is impossible

b) Illustrate over Test generation Strategies over a short note? Dec 2010

Soln:



These are crucial for the success of the test effort and the accuracy of test plan and estimates

Test generation strategies have the following major tasks:

- Designing the Tests

- Evaluating testability of the requirements and system.

Designing the test environment set-up and identifying any required infrastructure and tools.

Designing the Tests

- Transforms a source document into test designs.

- It involves a set of input values, execution preconditions, expected results and execution post

conditions, developed for a particular objective or test

condition, such as to exercise a particular program path or to verify compliance with a specific

requirement.

Types of Test Generation Strategies

Analytical Test Generation

Requirement Based Test Generation

Risk Based Test Generation

- Code based Test Generation

Program Mutation

Control Flow Based Test Generation

Model Based Test Generation

Mathematical Model for critical system behavior



• Requirements are modeled using a formal notations Examples: Finite State Machines, State

Charts, Pertrinets, Timed I/O Automata, Algebraic and predicate logic, Sequence and Activity

Diagram in UML

Quality Profiling Based Test Generation

Methodical Test Generation

c) Classify Dynamic Testing in Detail?

Ans: Static testing is a form of software testing where the software isn't actually used. This is in

contrast to dynamic testing. It is generally not detailed testing, but checks mainly for the sanity

of the code, algorithm, or document. It is primarily syntax checking of the code and/or manually

reviewing the code or document to find errors. This type of testing can be used by the developer

who wrote the code, in isolation. Code reviews, inspections and walkthroughs are also used.

From the black box testing point of view, static testing involves reviewing requirements and

specifications. This is done with an eye toward completeness or appropriateness for the task at

hand. This is the verification portion of Verification and Validation.Even static testing can be

automated. A static testing test suite consists of programs to be analyzed by an interpreter or a

compiler that asserts the programs syntactic validity.Bugs discovered at this stage of

development are less expensive to fix than later in the development cycle.

Objectives

To improve the quality of software work products by Assisting Engineers to recognize and fix

their own defects early in the software development process

Static Techniques

- Preventive quality measure taken to filter out errors in work products at the very point of their

injection so as to prevent them entering following phases



- It involves a visual static analysis of a work product, a meeting by technical people for

technical people

- Symbolizes maturity of organization

The formality of the review process is related to maturity of the development process

Static testing and static analysis

They have the same objective - identifying defects in order to prevent them from becoming more

expensive.

Two approaches to evaluation, revealing defects and quality.

Static testing:

Software work products are examined but not executed manually or using tools

Static analysis:

To find defects in software source code and software models.

UNIT 2


2a) Explain how CFG assists the tester in analysis of program to understand the behavior in

terms of flow of control with example? Jun/july 2011

Soln:

Program representation: Basic Blocks

A basic block in program P is a sequence of consecutive statements with a single entry and a

single exit point.



Thus a block has unique entry and exit points. Control always enters a basic block at its entry

point and leaves from its exit point.

There is no possibility of exit or a halt at any point inside the basic block except at its exit point.

The entry and exit points of a basic block coincide when the block contains only one statement.



A control flow graph (CFG) in computer science is a representation, using graph notation, of all

paths that might be traversed through a program during its execution.

Terms concerned to CFG:

These terms are commonly used when discussing control flow graphs.entry block block through

which all control flow enters the graph exit block block through which all control flow leaves the



graph back edge an edge that points to an ancestor in a depth-first (DFS) traversal of the graph

critical edge an edge which is neither the only edge leaving its source block, nor the only edge

entering its destination block. These edges must be split (a new block must be created in the

middle of the edge) in order to insert computations on the edge without affecting any other edges

abnormal edge an edge whose destination is unknown. Exception handling constructs can

produce them.

These edges tend to inhibit optimization impossible edge (also known as a fake edge) An edge

which has been added to the graph solely to preserve the property that the exit block

postdominates all blocks. It cannot ever be traversed dominator block M dominates block N if

every path from the entry that reaches block N has to pass through block M. The entry block

dominates all blocks. Postdominator block M postdominates block N if every path from N to the

exit has to pass through block M. The exit block postdominates all blocks.immediate dominator

block M immediately dominates block N if M dominates N, and there is no intervening block P

such that M dominates P and P dominates N. In other words, M is the last dominator on all paths

from entry to N. Each block has a unique immediate dominator. immediate postdominator

Analogous to immediate dominator.

C) Describe the following:- Jun/July 2011

I) S

ource of test generation:-



II) L

ife Cycle Phase:-

iii) Test Process Models:-



UNIT 2


2a What are Variety of ways in which Software testing in the Software development life cycle?

Dec/Jan 2011

Soln:-



b) Consider the following program?

Identify Basic Blocks,Entry Points,Exit points .Draw the Control flow graph?



Soln:-



UNIT 3

Test Generation from Requirements –I

3a) Explain the following May/June 2010

Equivalence Partitioning:-

Sol:- Equivalence partitioning is a software testing technique that divides the input data of a

software unit into partition of data from which test cases can be derived. In principle, test cases

are designed to cover each partition at least once. This technique tries to define test case that

uncovers classes of errors, thereby reducing the total number of test cases that must be

developed.



ii) Boundary Value Analysis:-

Boundary value analysis is software testing design technique in which tests are designed to

include representatives of boundary values. Values on the edge of an equivalence partition or at

the smallest value on either side of an edge are taken for testing. The values could be either input

or output ranges of a software component. Since these boundaries are common locations for

errors that result in software faults they are frequently exercised in test cases.

b) Explain the steps for creating equivalence classes for the given problem requirements?May/June 2010

Soln:-

Systematic procedure for equivalence partitioning:-

1.Identify the input domain: Read the requirements carefully and identify all input and output

variables, their types, and any conditions associated with their use.Environment variables, such

as class variables used in the method under test and environment variables in UNIX, Windows,

and other operating systems, also serve as input variables. Given the set of values each variable

can assume, an approximation to the input domain is the product of these sets.

2.Equivalence classing: Partition the set of values of each variable into disjoint subsets. Each

subset is an equivalence class. Together, the equivalence classes based Test Generation.On an

input variable partition the input domain. Partitioning the input domain using values of one

variable, is done based on the expected behavior of the program.Values for which the program is

expected to behave in the ``same way" are grouped together. Note that ``same way" needs to be

defined by the tester.

3. Combine equivalence classes: This step is usually omitted and the equivalence classes defined

for each variable are directly used to select test cases. However, by not combining the

equivalence classes, one misses the opportunity to generate useful tests.The equivalence classes

are combined using the multidimensional partitioning approach described earlier.



4. Identify infeasible equivalence classes: An infeasible equivalence class is one that contains a

combination of input data that cannot be generated during test. Such an equivalence class might

arise due to several reasons.For example, suppose that an application is tested via its GUI, i.e.

data is input using commands available in the GUI. The GUI might disallow invalid inputs by

offering a palette of valid inputs only. There might also be constraints in the requirements that

render certain equivalence infeasible.

c) Identify the steps in generation of tests in category partition Method? Explain any two?May/June 2010

Soln:- The Category partition Method is a systematic approach to the generation of test from

requirements. The method consists of a mix of manual and automated steps. A method for

creating functional test suites has been developed in which a test engineer analyzes the system

specification, writes a series of formal test specifications, and then uses a generator tool to

produce test descriptions from which test scripts are written.

The method consists of the following steps:

1. Decompose the functional specification into functional units that can be tested independently.

2. Identify the parameters (the explicit inputs to a functional unit) and environment conditions

(the state of the system at the time of execution) that affect the execution behavior of the

function.

3. Find categories (major properties or characteristics) of information that characterize each

parameter and environment condition.

4. Partition each category into choices, which include all the different kinds of values that are

possible for that category.

5. Determine the constraints among the choices of different categories. For example, one choice

may require that another is absent, or has a particular value.

6. Write the test specification (which is a list of categories, choices, and constraints in a

predefined format) using the test specification language TSL.

7. Use a generator to produce test frames from the test specification. Each generated test frame is

a set of choices such that each category contributes no more than one choice.

8. For each generated test frame, create a test case by selecting a single element from each choice

in that test frame.

UNIT 3


3a) Consider an application of your choice and condition Partiton the input domain using

Unidimensional and Multidimentional Partition?Test for above using equivalent classes?

Dec 2010

Soln:-

Consider an application that requires two integer inputs x and y. Each of these inputs is expected

to lie in the following ranges: 3£ x£7 and 5£y£9.

For one-dimensional partitioning we apply the partitioning guidelines to x and y individually.

This leads to the following six equivalence classes.

E1: x<3 E2: 3£x£7 E3: x>7 y ignored.

E1: x<3 E2: 3£x£7 E3: x>7 y ignored

For multidimensional partitioning we consider the input domain to be the set product X x Y. This

leads to 9 equivalence classes.

E1: x<3, y<5 E2: x<3, 5£y£9 E3: x<3, y>9

E4: 3£x£7, y<5 E5: 3£x£7, 5£y£9 E6: 3£x£7, y>9

E7: >7, y<5 E8: x>7, 5£y£9 E9: x>7, y>9

Systematic procedure

3b) Write Short notes on Dec 2010

i)Boundary Value Analysis

Boundary value analysis is software testing design technique in which tests are designed to

include representatives of boundary values. Values on the edge of an equivalence partition or at

the smallest value on either side of an edge are taken for testing. The values could be either input

or output ranges of a software component. Since these boundaries are common locations for

errors that result in software faults they are frequently exercised in test cases.

A Black Box Testing Method, complements to Equivalence partition and BVA leads to a

selection of test cases that exercise bounding values.

BVA: Procedure

1 Partition the input domain using one-dimensional partitioning. This leads to as many partitions

as there are input variables. Alternately, a single partition of an input domain can be created

using multidimensional partitioning. We will generate several sub-domains in this step.

2 Identify the boundaries for each partition. Boundaries may also be identified using special

relationships amongst the inputs.

3 Select test data such that each boundary value occurs in at least one test input. ii) Category

Partition Method:-



The Category partition Method is a systematic approach to the generation of test from

requirements.

The method consists of a mix of manual and automated steps. A method for creating functional

test suites has been developed in which a test engineer analyzes the system specification, writes a

series of formal test specifications, and then uses a generator tool to produce test descriptions

from which test scripts are written.

The main characteristics of the category-partition method include the following:

i)The test specification is a concise and uniform representation of the test information for a

function.

ii)The test specification can be easily modified, if this is necessitated by changes in the

functional specification of a command; mistakes in an original test specification; and a desire for

more or fewer test cases.

iii)The test specification gives the tester a logical way to control the volume of tests.

iv)The generator tool provides an automated way to produce thorough tests for each function,

and to avoid impossible or undesirable combinations of parameters and environments.

v) The method emphasizes both the specification coverage and the error detection aspects of

testing.

UNIT 3


3a) Explain the notation using Cause-effect Graphing and describe creation of cause effect graph

for GUI based Computer System? May/June 2011

Soln:-



The use of parameters qty and weight depends on the leftmost digit in code.

qty indicates the quantity purchased, an integer, when the left most digit is 0 or 3; weight

is ignored.

weight is the weight of the item purchased when the leftmost digit is 2; quantity is ignored.

qty is the value of the discount when the leftmost digit is 5; again weight is ignored.

when the leftmost digit is 5, the second digit from the left specifies dollar amount and the

third and fourth digits are cents.

Steps used in Category –Partition Method

Step 1: Analyze specification

In this step, the tester identifies each functional unit that can be tested separately. For large

systems, a functional unit may correspond to a subsystem that can be tested Independently.



The subsystem can be further subdivided leading to independently testable subunits.The

subdivision process terminates depending on what is to be tested.In this example, we assume that

fP is an independently testable subunit of an application.

Thus we will derive tests for fP.

Step 2: Identify Categories

For each testable unit, the given specification is analyzed and the inputs isolated.In addition, the

objects in the environment, for example, file also need to be identified.Next, the characteristics

of each parameter and environment object is determined. A characteristic is referred to as a

Category.Some characteristics are stated explicitly, others might need to be derived by a careful

examination of the Specification. fP has three input parameters: code, qty, weight.The

specification mention various characteristics of these Parameters such as their type and

interpretation. qty and weight are related to code.The database accessed by fP is an environment

object.

code: length, leftmost digit, remaining digits

qty: integer

weight: float

database: contents

Step 3: Partition Categories

For each category, the tester determines different cases against which the functional unit

must be tested. Each case is also referred as a choice. It is useful to partition each category into at

least two subsets, a set containing correct values and another consisting of erroneous values.

code: length

Valid (eight digits)



Invalid (less than or greater than eight digits)

leftmost digit 0 2 3 5 and others.

remaining digits valid string invalid string (eg. 0X5987Y) qty: integer valid quantity invalid

quantity (eg. 0) weight: float valid weight invalid weight (eg. 0) Environments:

database:contentsitem exists item does not exist

Step 4: Identify Constraints

A test for a functional unit consists of a combination of choices for each parameter and

environment object.

Certain combinations might not be possible while others must satisfy specific relationships.

Constraints among choices are specified in this step.

A constraint is specified using a property list and a selector Expression.

A property list has the following form:

[property P1, P2, ……]

where property is a key word and P1, P2 etc. are names of Individual properties.Each choice can

be assigned a property.A selector expression is a conjunction of pre-defined properties specified

in some property list.

A selector expression takes one of the form:

[if P]

[if P and P2 and..]

The above two forms can be suffixed to any choice.



A special property written [error] can be assigned to choices that represent error

conditions.Another special property as [single] allows the tester to specify that the associated

choice is not to be combined with choices of other parameters, or environment objects,while

generating test frames in step 6.

# Leftmost digit of code

0 [property ordinary-grocery]

2 [property variable-weight]

# Remaining digits of the code

valid string [single]

# Valid value of qty

valid quantity [if ordinary-grocery]

# Incorrect value of qty

invalid quantity [error]

Step 5: (Re) Write Test specification (TSL)

code:

length

Valid

Invalid [error]

leftmost digit

0 [property ordinary-grocery]



2 [property variable-weight]

3 [property Health-related]

5 [property Coupon]

remaining digits

Valid string

Invalid string [error]

qty:

Valid quantity

Invalid quantity [error]

weight:

Valid weight [if variable-weight]

Invalid weight [error]

Environments:

database:

contents

item exists

item does not exist [error]

Step 6: Process specification

Test case 2: (key = 1.2.1.0.1.1)



Length: valid

Leftmost digit: 2

Remaining digits: valid

qty: ignored

weight: 3.19

database: item exists

Step 7: Evaluate generator output

Step 8: Generate Test scripts

A test script is a group of test cases

b) Briefly explain procedure for generating BOR Constraint set and BRO Constraint set from

Abstract syntax Tree of ca predicate Pr? May/June 2011

Soln:-

Predicate testing: BOR testing criterion

A test set T that satisfies the BOR testing criterion for a compound predicate pr,guarantees the

detection of single or multiple Boolean operator faults in the implementation of pr.

T is referred to as a BOR-adequate test set and sometimes written as TBOR.

Predicate testing: BRO testing criterion

A test set T that satisfies the BRO testing criterion for a compound predicate pr,guarantees the

detection of single or multiple Boolean operator and relational operator faults in the

implementation of pr.

T is referred to as a BRO-adequate test set and sometimes written as TBRO.

Generation of BOR constraint set

We want to generate TBOR for: pr: ad

First, generate syntax tree of pr.

1. Generation of BOR constraint set

We will use the following notation:

SN is the constraint set for node N in the syntax tree for pr.

SNt is the true constraint set for node N in the syntax tree for pr.

SNf is the false constraint set for node N in the syntax tree for pr.

SN= SNt È SNf .

Second, label each leaf node with the constraint set {(t), (f)}.

We label the nodes as N1, N2, and so on for convenience.

Notice that N1 and N2 are direct descendents of N3 which is an AND-node.

Third, compute the constraint set for the next higher node in the syntax tree, in this case

N3. For an AND node, the formulae used are the following.

SN3t = SN1t Ä SN2t ={(t)} Ä {(t)}={(t, t)}

SN3f = (SN1f {t2})({t1}SN2f

= ({(f)} {(t)})({(t)}{(f)})

= {(f, t)}{(t, f)}

= {(f, t),{(t, f)}

Generation of TBOR

As per our objective, we have computed the BOR constraint set for the root node of the AST(pr).

We can now generate a test set using the BOR constraint set associated with the root node.

SN3 contains a sequence of three constraints and hence we get a minimal test set consisting of

three test cases. Here is one possible test set. TBOR ={t1, t2, t3}

t1=<a=1, b=2, c=6, d=5> (t, t)

t2=<a=1, b=0, c=6, d=5> (f, t)

t3=<a=1, b=2, c=1, d=2> (t, f)

ad

Ù

{(t), (f)}

N1 N2

N3

SN3={(t,t), (f, t), (t, f)}

ad

Ù {(t), (f)} {(t), (f)}

Generation of BRO constraint set

Recall that a test set adequate with respect to a BRO constraint set for predicate pr,guarantees the

detection of all combinations of single or multiple Boolean operator and relational operator

faults.

BRO constraint set

The BRO constraint set S for relational expression e1 relop e2:

S={(>), (=), (<)}

Separation of S into its true (St) and false (Sf)components:

relop: > St={(>)} Sf={(=), (<)}

relop: _ St={(>), (=)} Sf={(<)}

relop: = St={(=)} Sf={(<), (>)}

relop: < St={(<)} Sf={(=), (>)}

relop: _ St={(<), (=)} Sf={(>)}

Note: tN denotes an element of StN. fN denotes an element of SfN

BRO constraint set: Example

pr: (a+b<c)Ù!p Ú (r>s)

Step 1: Construct the AST for the given predicate.

P r>s Ù a+b<c ! Ú N1 N4 N2

Step 2: Label each leaf node with its constraint set S.

Step 3: Traverse the tree and compute constraint set for each internal node.

StN3=SN2f={(f)} SfN3=SN2t= {(t)}

StN4=SN1t Ä SN3t={(<)} Ä{(f)}={(<, f)}

SfN4= (SfN1 × {(tN3)}) È ({(tN1)} × SfN3)

=({(>,=)} ×{(f)}) È {(<)} ×{(t)})

={(>, f), (=, f)} È {(<, t)}

={(>, f), (=, f), (<, t)}

P r>s Ù a+b<c ! Ú N1N4N2N6N5N3

Next compute the constraint set for the root node (this is an OR-node).

SfN6=SfN4

={(>,f),(=,f),(<,t)} {(=),(<)}={(<, f)}

={(>,f,=), (=,f,<),(<,t,=)}

StN6= (StN4

=({(<,f)} {(=)}) {(>,f)} {(>)})

={(<,f,=)} {(>,f,>)}

={(<,f,=),(>,f,>)}

Constraint set for pr: (a+b<c)



UNIT 3


3a) What is Equivalence Partitioning? Explain Equivalence Partitioning with Boiler Control

System Example? Dec 2011

Soln:-

Boiler control example (BCS)

The control software of BCS, abbreviated as CS, is required to offer several options.One of the

options, C (for control), is used by a human operator to give one of four commands (cmd):

change the boiler temperature (temp), shut down the boiler (shut), and cancel the request

(cancel).

Command temp causes CS to ask the operator to enter the amount by which the temperature is to

be changed (tempch). Values of tempch are in the range -10..10 in increments of 5 degrees

Fahrenheit. An temperature change of 0 is not an option.

Selection of option C forces the BCS to examine variable V. If V is set to GUI, the operator is

asked to enter one of the three commands via a GUI. However, if V is set to file, BCS obtains the

command from a command file.

The command file may contain any one of the three commands, together with the value of the

temperature to be changed if the command is temp. The file name is obtained from variable F.



Values of V and F can be altered by a different module in BCS.

In response to temp and shut commands, the control software is required to generate appropriate

signals to be sent to the boiler heating system.

We assume that the control software is to be tested in a simulated environment. The tester takes

on the role of an operator and interacts with the CS via a GUI.

The GUI forces the tester to select from a limited set of values as specified in the requirements.

For example, the only options available for the value of tempch are -

10, -5, 5, and 10. We refer to these four values of tempch as t-valid while all other values as t-

invalid.

BCS: 1. Identify input domain

The first step in generating equivalence partitions is to identify the (approximate) input domain.

Recall that the domain identified in this step will likely be a superset of the complete input

domain of the control software.

First we examine the requirements, identify input variables, their types, and values.



These are listed in the following table.



3b) What is Boundary value Analysis?Explain the BVA Procedure by considering your Own

Example? Dec 2011

Soln:-



Unit-4

Test Generation from Requirements – II

4a) List the generic procedure which is used for generation of tests using Cause-effect graphing?May/June 2010

Soln:

Step one: Break the specification down into workable pieces.

First, the functional requirements are decomposed and analyzed.To do this, the functional

requirements are partitioned into logical groupings, for example, commands, actions, and menu

options.Each logical grouping is then further analyzed and decomposed into a list of detailed

functions, sub-functions, and so forth.

Step two: Identify the causes and effects.

a) Identify the causes (the distinct or equivalence classes of input conditions) and assign each

one a unique number.



Step three: The semantic content of the specification is analyzed and transformed into a Boolean

graph linking the causes and effects. This is the cause-effect graph.Semantics, in this step’s

instructions, reflect the meaning of the programs or functions.This meaning is discerned from the

specification and transformed into a boolean graph that maps the causes to the resulting effects.

Step four: Annotate the graph with constraints describing combinations of causes and/or effects

that are impossible because of syntactic or environmental constraints or considerations.

In most software programs, certain combinations of causes are impossible because of syntactic or

environmental considerations. For example, for the purpose of calculating insurance premium in

the above example, a person cannot be both a “Male” and a “Female” simultaneously.

4b) Explain the process of creating Cause effect Graphing? May/June 2010

Soln:-

Cause-Effect Graphing (CEG) is used to derive test cases from a given natural language

specification to validate its corresponding implementation. The CEG technique is a lackbox

method, i.e, it considers only the desired external behavior of a system Cause-Effect Graphing

technique derives the minimum number of test cases to cover 100% of the functional

requirements to improve the quality of test coverage.A cause-effect graph is “a graphical

representation of inputs or stimuli (causes) with their associated outputs (effects), which can be

used to design test cases”. Furthermore, cause-effect graphs contain directed arcs that represent

logical relationships between causes and effects.

Each arc can be influenced by Boolean operators.Such graphs can be used to design test cases,

which can directly be derived from the graph , or to visualize and measure the completeness and

the clearness of a test model for the tester.Cause-Effect Graphing is very similar to Decision

Table-Based Testing, where logical relationships of the inputs produce outputs; this is shown in

the form of a graph.The graph used is similar to that of a Finite State Machine (FSM). Symbols

are used to show the relationships between input conditions, those symbols are similar to the

symbols used in propositional logic.Cause-effect graphs are directed graphs with causes and

effects represented as nodes and connections between them represented as arcs.Each node is

labeled with a unique number or letter referencing a certain condition.

c) Explain fault model of Predicate Testing? May/June 2010

Soln:

Boolean operator fault: Suppose that the specification of a software module requires that an

action be performed when the condition (a<b) Ú (c>d) Ùe is true.Here a, b, c, and d are integer

variables and e is a Boolean variable. Correct predicate: (a<b) Ú (c>d) Ùe

(a<b) Ù (c>d) Ùe Incorrect Boolean operator

(a<b) Ú ! (c>d) Ùe Incorrect negation operator

(a<b) Ù(c>d) Ú e Incorrect Boolean operators

(a<b) Ú (e>d) Ùc Incorrect Boolean variable.

Relational operator faults

Correct predicate: (a<b) Ú (c>d) Ùe

(a==b) Ú (c>d) Ùe Incorrect relational operator

(a==b) Ú (c£d) Ùe Two relational operator faults

(a==b) Ú (c>d) Ú e Incorrect Boolean operators

Arithmetic expression faults

Correct predicate:Ec: e1 relop1 e2. Incorrect predicate: Ei: : e3 relop2 e4. Assume that Ec and Ei

use the same set of variables.

Ei has an off-by-e fault if |e3-e4|= e for any test case for which e1=e2.

Ei has an off-by-e* fault if |e3-e4|³ e for any test case for which e1=e2.

Ei has an off-by-e+ fault if |e3-e4|> e for any test case for which e1=e2.

Arithmetic expression faults: Examples

Correct predicate: Ec: a<(b+c). Assume e=1.

Ei: a<b. Given c=1, Ei has an off-by-1 fault as |a-b|= 1 for a test case for which a=b+c, e.g. <a=2,

b=1, c=1>.

Ei: a<b+1. Given c=2, Ei has an off-by-1* fault as |a-(b+1)|³ 1 for any test case for which a=b+c;

<a=4, b=2, c=2>

Ei: a<b-1. Given c>0, Ei has an off-by-1+ fault as |a-(b-1)|>1 for any test case for which a=b+c;

<a=3, b=2, c=1>.

Goal of predicate testing

Given a correct predicate pc, the goal of predicate testing is to generate a test set T such that

there is at least one test case tÎ T for which pc and its faulty version pi, evaluate to different truth

values.

Such a test set is said to guarantee the detection of any fault of the kind in the fault model

introduced above.

As an example, suppose that pc: a<b+c and pi: a>b+c. Consider a test set T={t1, t2}

where t1: <a=0, b=0, c=0> and t2: <a=0, b=1, c=1>.



Unit-4


4a) Devise a procedure for generation of Tests using Cause-effect graphing? Dec/Jan 2010

Soln:

Step one: Break the specification down into workable pieces.

First, the functional requirements are decomposed and analyzed.To do this, the functional

requirements are partitioned into logical groupings, for example, commands, actions, and menu

options.Each logical grouping is then further analyzed and decomposed into a list of detailed

functions, sub-functions, and so forth.

Step two: Identify the causes and effects.

a) Identify the causes (the distinct or equivalence classes of input conditions) and assign each

one a unique number.

Step three: The semantic content of the specification is analyzed and transformed into a Boolean

graph linking the causes and effects. This is the cause-effect graph.Semantics, in this step’s

instructions, reflect the meaning of the programs or functions.This meaning is discerned from the

specification and transformed into a boolean graph that maps the causes to the resulting effects.

Step four: Annotate the graph with constraints describing combinations of causes and/or effects

that are impossible because of syntactic or environmental constraints or considerations.

In most software programs, certain combinations of causes are impossible because of syntactic or

environmental considerations. For example, for the purpose of calculating insurance premium in

the above example, a person cannot be both a “Male” and a “Female” simultaneously.

b) What is Predicate Testing its fault model and testing Criteria? Dec/Jan 2010
















Correct predicate:Ec: e1 relop1 e2. Incorrect predicate: Ei: : e3 relop2 e4. Assume that

Ec and Ei use the same set of variables.






Ei: a<b. Given c=1, Ei has an off-by-1 fault as |a-b|= 1 for a test case for which a=b+c,

e.g. <a=2, b=1, c=1>.

Ei: a<b+1. Given c=2, Ei has an off-by-1* fault as |a-(b+1)|³ 1 for any test case for

which a=b+c; <a=4, b=2, c=2>

Ei: a<b-1. Given c>0, Ei has an off-by-1+ fault as |a-(b-1)|>1 for any test case for which

a=b+c; <a=3, b=2, c=1>.




values.


introduced above.

Correct predicate:Ec: e1 relop1 e2. Incorrect predicate: Ei: : e3 relop2 e4. Assume that Ec and Ei

use the same set of variables.






Ei: a<b. Given c=1, Ei has an off-by-1 fault as |a-b|= 1 for a test case for which a=b+c,

e.g. <a=2, b=1, c=1>.

Ei: a<b+1. Given c=2, Ei has an off-by-1* fault as |a-(b+1)|³ 1 for any test case for which a=b+c;

<a=4, b=2, c=2>

Ei: a<b-1. Given c>0, Ei has an off-by-1+ fault as |a-(b-1)|>1 for any test case for which

a=b+c; <a=3, b=2, c=1>.





values.


introduced above.



Unit-4


4a) Explain the Notations used in Cause-effect Graphing & describe the creation of cause-effect

graph for GUI based computer system? Jun/July 2011

Soln:

The starting point for the Cause-Effect Graph is the requirements document.The requirements

describe “what” the system is intended to do.The requirements can describe real time systems,

events, data driven systems, state transition diagrams, object oriented systems, graphical user

interface standards, etc. Any type of logic can be modeled using a Cause-Effect diagram.Each

cause (or input) in the requirements is expressed in the cause-effect graph as a condition, which

is either true or false.Each effect (or output) is expressed as a condition, which is either true or

false.In CEG analysis, first, identify causes, Effects and constraints in the (natural language)

specification.Second, construct a CEG as a combinational logic network which consists of

nodes,called causes and effects, arcs with Boolean operators (and, or, not) between causes and

effects, and constraints.Finally, trace this graph to build a decision table which may be

subsequently converted into use cases and eventually, test cases. The starting point for the

Cause-Effect Graph is the requirements document.The requirements describe “what” the system

is intended to do.

The requirements can describe real time systems, events, data driven systems, state transition

diagrams, object oriented systems, graphical user interface standards, etc. Any type of logic can

be modeled using a Cause-Effect diagram. Each cause (or input) in the requirements is expressed

in the cause-effect graph as a condition, which is either true or false. Each effect (or output) is

expressed as a condition, which is either true or false. In CEG analysis, first, identify causes,

Effects and constraints in the (natural language) specification.Second, construct a CEG as a

combinational logic network which consists of nodes,called causes and effects, arcs with

Boolean operators (and, or, not) between causes and effects, and constraints.Finally, trace this

graph to build a decision table which may be subsequently converted into use cases and

eventually, test cases.

b) Briefly explain procedure for generating BOR Constraint set and BRO Constraint set from

Abstract syntax Tree of ca predicate Pr? Jun/July 2011

Soln:-

Predicate testing: BOR testing criterion

A test set T that satisfies the BOR testing criterion for a compound predicate pr,guarantees the

detection of single or multiple Boolean operator faults in the implementation of pr.

T is referred to as a BOR-adequate test set and sometimes written as TBOR.

Predicate testing: BRO testing criterion

A test set T that satisfies the BRO testing criterion for a compound predicate pr,guarantees the

detection of single or multiple Boolean operator and relational operator faults in the

implementation of pr.

T is referred to as a BRO-adequate test set and sometimes written as TBRO.

Generation of BOR constraint set

We want to generate TBOR for: pr: ad



First, generate syntax tree of pr.

1. Generation of BOR constraint set

We will use the following notation:

SN is the constraint set for node N in the syntax tree for pr.

SNt is the true constraint set for node N in the syntax tree for pr.

SNf is the false constraint set for node N in the syntax tree for pr.

SN= SNt È SNf .

Second, label each leaf node with the constraint set {(t), (f)}.

We label the nodes as N1, N2, and so on for convenience.

Notice that N1 and N2 are direct descendents of N3 which is an AND-node.

Third, compute the constraint set for the next higher node in the syntax tree, in this case

N3. For an AND node, the formulae used are the following.

SN3t = SN1t Ä SN2t ={(t)} Ä {(t)}={(t, t)}

SN3f = (SN1f {t2})({t1}SN2f

= ({(f)} {(t)})({(t)}{(f)})

= {(f, t)}{(t, f)}

= {(f, t),{(t, f)}

Generation of TBOR

As per our objective, we have computed the BOR constraint set for the root node of the AST(pr).

We can now generate a test set using the BOR constraint set associated with the root node.

SN3 contains a sequence of three constraints and hence we get a minimal test set consisting of

three test cases. Here is one possible test set.

TBOR ={t1, t2, t3}

t1=<a=1, b=2, c=6, d=5> (t, t)

t2=<a=1, b=0, c=6, d=5> (f, t)

t3=<a=1, b=2, c=1, d=2> (t, f)

ad

Ù{(t), (f)}N1 N2N3

Generation of BRO constraint set

Recall that a test set adequate with respect to a BRO constraint set for predicate pr, guarantees

the detection of all combinations of single or multiple Boolean operator and relational operator

faults.

BRO constraint set

The BRO constraint set S for relational expression e1 relop e2:

S={(>), (=), (<)}

Separation of S into its true (St) and false (Sf)components:

relop: > St={(>)} Sf={(=), (<)}

relop: _ St={(>), (=)} Sf={(<)}

relop: = St={(=)} Sf={(<), (>)}

relop: < St={(<)} Sf={(=), (>)}

relop: _ St={(<), (=)} Sf={(>)}

Note: tN denotes an element of StN. fN denotes an element of SfN

BRO constraint set: Example

pr: (a+b<c)Ù!p Ú (r>s)

Step 1: Construct the AST for the given predicate.

P r>s Ù a+b<c ! Ú N1 N4 N2

Step 2: Label each leaf node with its constraint set S.

Step 3: Traverse the tree and compute constraint set for each internal node.

StN3=SN2f={(f)} SfN3=SN2t= {(t)}

StN4=SN1t Ä SN3t={(<)} Ä{(f)}={(<, f)}

SfN4= (SfN1 × {(tN3)}) È ({(tN1)} × SfN3)

=({(>,=)} ×{(f)}) È {(<)} ×{(t)})

={(>, f), (=, f)} È {(<, t)}

={(>, f), (=, f), (<, t)}

Next compute the constraint set for the root node (this is an OR-node).

SfN6=SfN4

={(>,f),(=,f),(<,t)}

={(>,f,=), (=,f,<),(<,t,=)}

StN6= (StN4

=({(<,f)}

={(<,f,=)}

={(<,f,=),(>,f,>)}

Constraint set for pr: (a+b<c)

Unit-4


4a) Explain Cause effect graphing with examples and Show basic elements of Cause effect

graphing? Dec 2011

Soln:

I have a requirement that says: “If A OR B, then C.” The following rules hold for this

requirement:

• If A is true and B is true, then C is true.

• If A is true and B is false, then C is true.

• If A is false and B is true, then C is true.

• If A is false and B is false, then C is false.

The cause-effect graph that represents this requirement is provided in Figure.

101 ,1 100,2,3



In Figure, A, B and C are called nodes. Nodes A and B are the causes, while Node C is

an effect. Each node can have a true or false condition. The lines, called vectors, connect the

cause nodes A and B to the effect node C. All requirements are translated into nodes and

relationships on the cause-effect graph. There are only four possible relationships among

nodes, and they are indicated by the following symbols: Where A always leads to C, a

straight line ------------. Where A or B lead to C, a V at the intersection means “or”. Where A

and B lead to C, an inverted V at the intersection means “and”. A tilde ~ means “not” as in “If

not A, then C”. have a true or false condition. The lines, called vectors, connect the cause nodes

A and B to the effect of C. There are only four possible relationships among nodes, and they

are indicated by the following symbols: Where A always leads to C, a straight line ------------.

Where A or B lead to C, a V at the intersection means “or”.

b) What is goal of predicate Testing? Explain Boolean or extra faults with an example? Dec 2011

Test generation from predicates

We will now examine two techniques, named BOR and BRO for generating tests that are

guaranteed to detect certain faults in the coding of conditions. The conditions from which tests are

generated might arise from requirements or might be embedded in the program to be tested.

Conditions guard actions.

For example,

if condition then action Is a typical format of many functional requirements.

Predicates

Relational operators (relop): {<, £, >, ³, =, ¹.} = and == are equivalent.

Boolean operators (bop): {!,Ù,Ú, xor} also known as {not, AND, OR, XOR}.

Relational expression: e1 relop e2. (e.g. a+b<c)

e1 and e2 are expressions whose values can be compared using relop.

Simple predicate: A Boolean variable or a relational expression. (x<0)

Compound predicate:

Join one or more simple predicates using bop. (gender==“female”Ùage>65)

Boolean expressions

Boolean expression: one or more Boolean variables joined by bop. (aÙbÚ!c) a, b, and c are also

known as literals. Negation is also denoted by placing a bar over a

Boolean expression such as in (aÙb). We also write ab for aÙb and a+b for aÚb when

there is no confusion. Singular Boolean expression: When each literal appears only once, e.g.

(aÙbÚ!c)

Disjunctive normal form (DNF): Sum of product terms:

e.g. (p q) +(rs) + (a c).

Conjunctive normal form (CNF): Product of sums:

e.g.: (p+q)(r+s)(a+c)

Any Boolean expression in DNF can be converted to an equivalent CNF and vice versa.

e.g.CNF: (p+!r)(p+s)(q+!r)(q+s) is equivalent to DNF: (pq+!rs)

Mutually singular: Boolean expressions e1 and e2 are mutually singular when they do not

share any literal.

If expression E contains components e1, e2,.. then ei is considered singular only if it is

non-singular and mutually singular with the remaining elements of E.



Unit 5

STRUCTURAL TESTING

5a) Explain Branch Testing with an example? May/June 2010

Soln:

Branch Testing

Adequacy criterion: each branch (edge in the CFG) must be executed at least once. The branch

coverage Cbranch of T for P is the fraction of branches of program P executed by at least one

test case in T.

T satisfies the branch adequacy criterion if Cbranch =1

C Branch: # executed branches # branches

Eg: T3 = {“”, “+%0D+%4J”} 100% Stmt Cov. 88% Branch Cov. (7/8 branches)

T2 = {“%3D”, “%A”, “a+b”, “test”} 100% Stmt Cov. 100% Branch Cov. (8/8 branches)

b) Explain Procedure call Testing & Path Testing? May/June 2010

Soln:

Path adequacy: A test suite T for P satisfies the Path adequacy criterion iff for each path p of P

there exists at least one test case in T that causes the execution of P Adequacy criterion: each

path must be executed at least once, so it helps in revealing failures that occurs when loop

executed several times The path coverage cpath of T for P is the fraction of paths of program P

executed by at least one test case in T

Coveragepath: # executed paths

# paths



To ensure finite number of paths we must limit the no of times of execution of each loop eg:10

iterations, 50 iterations etc.

Procedural Testing:-

Each set, or partition, contains values that are expected to be processed by the component in the

same way. Partitioning of test data ranges is explained in the equivalence partitioning test case

design technique. It is important to consider both valid and invalid partitions when designing test

cases.

The boundaries are the values on and around the beginning and end of a partition. If possible test

cases should be created to generate inputs or outputs that will fall on and to either side of each

boundary. This would result in three cases per boundary.



c) Explain in detail Condition testing and infeasibility problem? May/June 2010

Soln:

The expected input and output values should be extracted from the component specification. The

input and output values to the software component are then grouped into sets with identifiable

boundaries. Each set, or partition, contains values that are expected to be processed by the

component in the same way. Partitioning of test data ranges is explained in the equivalence

partitioning test case design technique. It is important to consider both valid and invalid

partitions when designing test cases.

The boundaries are the values on and around the beginning and end of a partition. If possible test

cases should be created to generate inputs or outputs that will fall on and to either side of each

boundary. This would result in three cases per boundary.



Adequacy criterion: each path must be executed at least once, so it helps in revealing failures that

occurs when loop executed several times. The path coverage cpath of T for P is the fraction of athsof

program P executed by at least one test case in T

Boundary interior path testing : A program may contain both looping and non looping statement,but

coverage of non-looping paths is expensive therefore we consider variant of the boundary / interior

criterion. Group together paths that differ only in the sub path they follow when repeating the body

of a loop, Follow each path in the control flow graph up to the first repeated node The set of paths

from the root of the tree to each leaf is the required set of sub paths for boundary/interior coverage



Unit 5

STRUCTURAL TESTING

5a) List the elements of control flow ?Discuss them with Testing,Adequacy criteria & Coverage?Dec 2010

Soln:



b) Explain Procedure Call Testing? Dec 2010

Soln:

The criteria considered to this point measure coverage of control flow within individual

procedures. not well suited to integration or system testing Choose a coverage granularity

commensurate with the granularity of testing if unit testing has been effective, then faults that

remain to be found in integration testing will be primarily interface faults, and testing effort

should focus on interfaces between units rather than their internal details

Procedure entry and exit testing

procedure may have multiple entry points (e.g., Fortran) and multiple exit points Call coverage

The same entry point may be called from many points

Subsumes Relation

Test coverage criterion A subsumes test coverage criterion B iff, for every program p, every test

satisfying A with respect to P also satisfies B with respect P.

The power and the cost of the structural test adequacy criteria can be formally compared using

the subsumes relation

They are divided in to 2 broad categories

1. practical criteria can be always satisfied by test set whose size is linear function of program

size.

2.theoretical criteria may require large no of test cases or infinite no of test cases.



Unit-5

STRUCTURAL TESTING

5a) Describe the Statement Testing & Branch Testing? July 2011

Soln:

Statement Testing

Adequacy criterion: each statement (or node in the CFG) must be executed at least once so that

the faulty statement can be revealed.

If T is a test suite for program P. T satisfies the statement adequacy criterion for P iff each

statement S of P, there exists at least one test case in T that causes execution of S.

Coverage= # executed statements

# statements

T satisfies statement adequacy criterion if c-stat = 1

Rationale: a fault in a statement can only be revealed by executing the faulty statement

The statement coverage c-stat of T for program P is the fraction of statement of program P


Eg:

T0 = {“”, “test”, “test+case%1Dadequacy”} 17/18 = 94% Stmt Coverage.

T1 = {“adequate+test%0Dexecution%7U”} 18/18 = 100% Stmt Coverage.

T2 = {“%3D”, “%A”, “a+b”,“test”} 18/18 = 100% Stmt Coverage.



Branch Testing



test case in T


C Branch: # executed branches

# branches

b) Explain path testing for a C Function for searching to nearly and dynamically re-arranging the

linked lists?also describe CFG for above fn? July 2011

Soln:

Path adequacy: A test suite T for P satisfies the Path adequacy criterion iff for each path p of P

there exists at least one test case in T that causes the execution of P Adequacy criterion: each

path must be executed at least once, so it helps in revealing failures that occurs when loop

executed several times The path coverage cpath of T for P is the fraction of paths of program P


Coveragepath: # executed paths

# paths

Boundary interior path testing : A program may contain both looping and non looping statement,

but coverage of non-looping paths is expensive therefore we consider variant of the boundary /

interior criterion.

Group together paths that differ only in the sub path they follow when repeating the body of a

loop ,Follow each path in the control flow graph up to the first repeated node



The set of paths from the root of the tree to each leaf is the required set of sub paths for

boundary/interior coverage

Unit-5

STRUCTURAL TESTING

5a) What is structural testing?explain Statement and branch testing with an example? Dec 2011

Soln:

Statement Testing

Adequacy criterion: each statement (or node in the CFG) must be executed at least once so that

the faulty statement can be revealed.

If T is a test suite for program P. T satisfies the statement adequacy criterion for P iff each

statement S of P, there exists at least one test case in T that causes execution of S.

Coverage= # executed statements

# statements



T satisfies statement adequacy criterion if c-stat = 1

Rationale: a fault in a statement can only be revealed by executing the faulty statement

The statement coverage c-stat of T for program P is the fraction of statement of program P


Eg:

T0 = {“”, “test”, “test+case%1Dadequacy”} 17/18 = 94% Stmt Coverage.

T1 = {“adequate+test%0Dexecution%7U”} 18/18 = 100% Stmt Coverage.

T2 = {“%3D”, “%A”, “a+b”,“test”} 18/18 = 100% Stmt Coverage.

Branch Testing



test case in T


C Branch: # executed branches

# branches

b) Distinguish between White Box and Black box testing? Dec 2011

Soln:

The Differences Between Black Box Testing and White Box Testing are listed below.

Criteria Black Box Testing White Box Testing

Definition Black Box Testing is a software testing White Box Testing is a software



method in which the internal structure/

design/ implementation of the item

being tested is NOT known to the tester

testing method in which the internal

structure/ design/ implementation of

the item being tested is known to the

tester.

Levels

Applicable To

Mainly applicable to higher levels of

testing:Acceptance Testing

System Testing

Mainly applicable to lower levels of

testing:Unit Testing

Integration Testing

ResponsibilityGenerally, independent Software

TestersGenerally, Software Developers

Programming

KnowledgeNot Required Required

Implementation

KnowledgeNot Required Required

Basis for Test

CasesRequirement Specifications Detail Design

c) What is Path testing?Draw the flow graph for finding out biggest of 3 numbers and calculate the

cyclomatic complexity? Dec 2011





test case in T



UNIT - 6

DEPENDENCE, DATA FLOW MODELS, AND DATA FLOW TESTING

6a) What do you understand by Definition use pair?Draw the Control flow graph for GCD?

June 2010

Soln:

DU pair: a pair of definition and use for some variable, such that at least one DU path exists from

the definition to the use.

public class GCD {

public int gcd(int x, int y) {

int tmp; // A: def x, y, tmp

while (y != 0) { // B: use y

tmp = x % y; // C: def tmp; use x, y

x = y; // D: def x; use y

y = tmp; // E: def y; use tmp

}

return x; // F: use x

}

Reach(E) = ReachOut(D)

ReachOut(E) = (Reach(E) \ {yA}) È {yE}




The first (simple) equation says that values can reach E by going through D.


This describes what happens at D. The previous definition of y at node A is overwritten. A new

value of y is defined here at line E.

We can associate two data flow equations of this form (what reached here, and what this node

changes) for every line in the program or node in the control flow graph.

b) Explain Data flow analysis and classic analysis? June 2010

Soln:

Data flow analysis with arrays and pointers

Arrays and pointers introduce uncertainty: Do different expressions access the same storage?

a[i] same as a[k] when i = k

a[i] same as b[i] when a = b (aliasing)

The uncertainty is accomodated depending to the kind of analysisAny-path: gen sets should

include all potential aliases and kill set should include only what is definitely modified

All-path: vice versa

One way to iterate to a fixed point solution. General idea: Initially all nodes are on the work

list,and have default values -Default for “any-path” problem is the empty set, default for “all-

path” problem is the set of all possibilities (union of all gen sets) While the work list is not

empty- Pick any node n on work list; remove it from the list -Apply the data flow equations for

that node to get new values



-If the new value is changed (from the old value at that node), then Add successors (for forward

analysis) or predecessors (for backward analysis) on the work list Eventually the work list will

be empty (because new computed values = old values for each node) and the algorithm stops.

This is a classic iteration to a fixed point. Perhaps the only subtlety is how we initialize values.

c) Explain in detail Dataflow testing Criteria? June 2010

Soln:

Adequacy criteria

The All DU pairs adequacy criterion requires each DU pair is exercised by at least one test case

All DU paths: Each simple (non looping) DU path is exercised by at least one test case

CDUpath = # of exercised simple DU paths

# of simple DU paths

All definitions: For each definition, there is at least one test case which exercises a DU pair

containing it (Every computed value is used somewhere) Corresponding coverage fractions can

also be defined

CDU pairs = # of exercised DU pairs

---------------------------

# of Du pairs

Difficult cases

x[i] = ... ; ... ; y = x[j]

DU pair (only) if i==j



p = &x ; ... ; *p = 99 ; ... ; q = x

*p is an alias of x

m.putFoo(...); ... ; y=n.getFoo(...);

Are m and n the same object?

Do m and n share a “foo” field?

Problem of aliases: Which references are (always or sometimes) the same?

Data flow coverage with complex structures

Arrays and pointers are critical for data flow analysis Under-estimation of aliases may fail to

include some DU pairs Over-estimation, on the other hand, may introduce unfeasible test

obligations For testing, it may be preferrable to accept under-estimation of alias set rather than

over-estimation or expensive analysis

• Controversial: In other applications (e.g., compilers), a conservative over-estimation of aliases

is usually required Alias analysis may rely on external guidance or other global analysis to

calculate good estimates.

• Undisciplined use of dynamic storage, pointer arithmetic, etc. may make the whole analysis

infeasible

Infeasibility

The path-oriented nature of data flow analysis makes the infeasibility problem especially

relevant Combinations of elements matter! Impossible to (infallibly) distinguish feasible from

infeasible paths. More paths = more work to check manually. In practice, reasonable coverage is

(often, not always) achievable Number of paths is exponential in worst case, but often linear

All DU paths is more often impractical



• Not all elements of a profram are executable

• The path –oriented nature of data flow aggravates the problem

• Infeasibility creates test obligation not only for isolated unexecutable elements but also for

infeasible combinations of feasible elements.

• Complex data strucutre may amplify the infeasibility problem by adding infeasible paths as a

result of alias computation

Eg:x[i] alias of x[j] when i=j cant determine when i = j in prg exe.

• But problem of infeasible path modest in DU pair adequacy criteria.

UNIT - 6


6 a) Explain Definition use pair with an example? December 2010


the definition to the use.

public class GCD {



while (y != 0) { // B: use y






}


}






b) What is reaching Definition? Illustrate with an algorithm by applying flow equation?

Dec 2010

Soln:

An efficient algorithm for computing reaching definitions (and several other properties) is based

on the way reaching definitions at one node are related to the reaching definitions at an adjacent

node. Suppose we are calculating the reaching definitions of node n, and there is an edge (p,n)

from an immediate predecessor node p.

If the predecessor node p can assign a value to variable v, then the definition vp reaches n. We

say the definition vp is generated at p.

If a definition vp of variable v reaches a predecessor node p, and if v is not redefined at that node

(in which case we say the vp is killed at that point), then the definition is propagated on from p to

n.

public class GCD {





while (y != 0) { // B: use y




}


}






This describes what happens at D. The previous definition of y at node A is overwritten. A new

value of y is defined here at line E.

We can associate two data flow equations of this form (what reached here, and what this node

changes) for every line in the program or node in the control flow graph.

General equation for reaching analysis



Each node of the control flow graph (or each line of the program) can be associated with set

equations of the same general form, with “gen” and “kill”

For reaching definitions, the “gen” set is just the variable that gets a new value there. It could be

the empty set if no variable is changed in that line.

The “kill” set is the set of values that will be replaced.

The subscripts here are the lines or nodes where the assignment takes place, so that we can keep

track of different assignments to the same variable.

For example, v99 would represent a value that v received at node (or line) 99.

Reach(n) = È ReachOut(m)

mÎpred(n)

ReachOut(n) = (Reach(n) \ kill (n)) È gen(n)

gen(n) = { vn | v is defined or modified at n }

kill(n) = { vx | v is defined or modified at x, x_n }

Avail equations

Available expressions” is another classic data flow analysis. An expression becomes available

where it is computed, and remains available until one of the variables in the expression is

changed. Unlike “reaching definitions”, though, it is not enough for an expression to be available

on ANY path to a node. Rather, it has to be available on ALL paths to the node.Avail (n) = Ç

AvailOut(m)

mÎpred(n)

AvailOut(n) = (Avail (n) \ kill (n)) È gen(n)



gen(n) = { exp | exp is computed at n }

kill(n) = { exp | exp has variables assigned at n }

• The gen and kill sets are different, reflecting the definition

• We use intersection instead of union when there is more than one path to a node, because this is

an “all paths” analysis rather than an “any paths” analysis

c) Define Various Data flow testing Criteria? Dec 2010

Soln:

Intraprocedural :Within a single method or procedure as described so far,Interprocedural:Across

several methods (and classes) or procedures Cost/Precision trade-offs for interprocedural

analysis are critical, and difficult context sensitivity

A context-sensitive (interprocedural) analysis distinguishes sub() called from foo() from sub()

called from bar();



UNIT - 6


6a) Describe the algorithms for available expressions classic data flow analysis with an example

using Control Flow graph? July 2011

Soln:

Avail equations

Available expressions” is another classic data flow analysis. An expression becomes available

where it is computed, and remains available until one of the variables in the expression is

changed. Unlike “reaching definitions”, though, it is not enough for an expression to be available

on ANY path to a node. Rather, it has to be available on ALL paths to the node.

Avail (n) = Ç AvailOut(m)

mÎpred(n)

AvailOut(n) = (Avail (n) \ kill (n)) È gen(n)

gen(n) = { exp | exp is computed at n }



kill(n) = { exp | exp has variables assigned at n }

• The gen and kill sets are different, reflecting the definition

• We use intersection instead of union when there is more than one path to a node, because this is

an “all paths” analysis rather than an “any paths” analysis

Live variable equations

Live variables is a third, classic data flow analysis. A variable is “live” at a node if the value that

is currently in the variable may be used later (before being replaced by another value). It is an

any-paths property like reaching definitions Note what is different here: We look at successors to

the current node, rather than predecessors. We say “live” is a backward analysis, while reach and

avail were forward analyses.

Live(n) = È LiveOut(m)

mÎsucc(n)

LiveOut(n) = (Live(n) \ kill (n)) È gen(n)

gen(n) = { v | v is used at n }

kill(n) = { v | v is modified at n }

classification analysis

Forward/backward: a node’s set depends on that of its predecessors/successors

Any-path/all-path: a node’s set contains a value iff it is coming from any/all of its inputs



Example: Taintedness (in web form processing)

“Taint”: a user-supplied value (e.g., from web form) that has not been validated

Gen: we get this value from an untrusted source here

Kill: we validated to make sure the value is proper

6b) Explain Data fllow testing criteria & Data flow testing coverage with Complex structures?

Adequacy criteria


All DU paths: Each simple (non looping) DU path is exercised by at least one test case

CDUpath = # of exercised simple DU paths

# of simple DU paths


containing it (Every computed value is used somewhere) Corresponding coverage fractions can

also be defined




---------------------------

# of Du pairs


---------------------------

# of Du pairs

Difficult cases

x[i] = ... ; ... ; y = x[j]

DU pair (only) if i==j

p = &x ; ... ; *p = 99 ; ... ; q = x

*p is an alias of x

m.putFoo(...); ... ; y=n.getFoo(...);

Are m and n the same object?

Do m and n share a “foo” field?

Problem of aliases: Which references are (always or sometimes) the same?

Data flow coverage with complex structures

UNIT - 6


6a) Explain data flow analysis with arrays and pointers? December 2011

Soln:



Data flow analysis with arrays and pointers

Arrays and pointers introduce uncertainty: Do different expressions access the same storage?

a[i] same as a[k] when i = k

a[i] same as b[i] when a = b (aliasing)

The uncertainty is accomodated depending to the kind of analysisAny-path: gen sets should

include all potential aliases and kill set should include only what is definitely modified All-path:

vice versa

Scope of Data Flow Analysis

Intraprocedural :Within a single method or procedure as described so far,Interprocedural:Across

several methods (and classes) or procedures Cost/Precision trade-offs for interprocedural

analysis are critical, and difficult context sensitivity

A context-sensitive (interprocedural) analysis distinguishes sub() called from foo() from sub()

called from bar();

6b) What is dataflow testing?Explain data flow testing criteria? Dec 2011

Adequacy criteria


All DU paths: Each simple (non looping) DU path is exercised by at least one test case CDUpath

= # of exercised simple DU paths # of simple DU paths


containing it (Every computed value is used somewhere)

Corresponding coverage fractions can also be defined




---------------------------

# of Du pairs


the definition to the use

x = ... is a definition of x

= ... x ... is a use of x

DU path: a definition-clear path on the CFG starting from a definition to a use of a same

Variable Definition clear: Value is not replaced on path

Note – loops could create infinite DU paths between a def and a use.

UNIT - 7

TEST CASE SELECTION AND ADEQUACY, TEST EXECUTION

7.a) Explain Test Case,Test case Specification,Test Suite,Adequacy Criteria? June 2010

Soln:

Test case: a set of inputs, execution conditions, and a pass/fail criterion.

Test case specification: a requirement to be satisfied by one or more test cases.

• Test obligation: a partial test case specification, requiring some property deemed important to

thorough testing.

• Test suite: a set of test cases.

• Test or test execution: the activity of executing test cases and evaluating their results.



• Adequacy criterion: a predicate that is true (satisfied) or false (not satisfied) of a

_program, test suite_ pair.

The design of software testing can be a challenging process. However software engineers often

see testing as an after thought, producing test cases that feel right but have little assurance that

they are complete. The objective of testing is to have the highest likelihood of finding the most

errors with a minimum amount of timing and effort. A large number of test case design methods

have been developed that offer the developer with a systematic approach to testing. Methods

offer an approach that can ensure the completeness of tests and offer the highest likelihood for

uncovering errors in software.

A Test Case Includes input, the expected output, pass/fail criteria and the environment inwhich

the test is being conducted. Here the term input means all the data that is required tomake a test

case. A Test Case specification is a requirement to be satisfied by one or more test cases.

Specification-based testing uses the specification of the program as the point of reference for test

input data selection and adequacy. A test specification can be drawn from system, interface or

program. The distinction between a test case and test specification is similar to the distinction

between program specification and program.

Software products can be tested in two ways:

(1) Knowing the specified functions that the product has been designed to perform, tests can be

performed that show that each function is fully operational

(2) knowing the internal workings of a product, tests can be performed to see if they jell.

The first test approach is known as a black box testing and the second white box testing.

Software Test cases derived from test specifications based on system requirements are generally

termed as functional or black box testing.

7b) Explain in detail Scaffolding and test oracles with respect to Test Execution? June 2010

Soln:



Code produced to support development activities (especially testing), Not part of the “product”

as seen by the end user May be temporary (like scaffolding in construction of buildings Includes

Test harnesses, drivers, and stubs.

• Test driver

– A “main” program for running a test

• May be produced before a “real” main program

• Provides more control than the “real” main program

– To driver program under test through test cases

• Test stubs

– Substitute for called functions/methods/objects

• Test harness

– Substitutes for other parts of the deployed environment

• Ex: Software simulation of a hardware device

Test Oracles

– Did this test case succeed, or fail? ,No use running 10,000 test cases automatically if the results

must be checked by hand!

– Range of specific to general, again, ex. JUnit: Specific oracle (“assert”) coded by hand in each

test case

– Typical approach: “comparison-based” oracle with predicted output value ,Not the only

approach!



cat

An oracle can also be written as self-checks -Often possible to judge correctness without

predicting results.

– Advantages and limits: Usable with large, automatically generated test suites, but often only a

partial check e.g., structural invariants of data structures, recognize many or most failures, but

not all.

7c) Discuss Testcase Specification to test cases & Capture and replay? June 2010

Soln:

Test design often yields test case specifications, rather than concrete data

– Ex: “a large positive number”, not 420023

– Ex: “a sorted sequence, length > 2”, not “Alpha, Beta, Chi, Omega”

• Other details for execution may be omitted



• Generation creates concrete, executable test cases from test case specifications

Example Tool Chain for Test Case Generation & Execution:

We could combine ... A combinatorial test case generation (like genpairs.py) to create test

data Optional: Constraint-based data generator to “concretize” individual values, e.g.,

from “positive integer” to 42

– DDSteps to convert from spreadsheet data to JUnit test cases

– JUnit to execute concrete test cases

• Many other tool chains are possible depending on application domain

Capture and Replay

– Sometimes there is no alternative to human input and observation: Even if we separate

testing program functionality from GUI, some testing of the GUI is required We can at least cut

repetition of human testing

- Capture a manually run test case, replay it automatically with a comparison-based test

oracle: behavior same as previously accepted behavior reusable only until a program change

invalidates it lifetime depends on abstraction level of input and output

UNIT - 7


7.a) Define Test Case,Test case Specification,Test Suite,Adequacy Criteria,Test Obligation? Dec

2010

Soln:


• Test case specification: a requirement to be satisfied by one or more test cases.




thorough testing.



• Adequacy criterion: a predicate that is true (satisfied) or false (not satisfied) of a _program,

test suite_ pair.

7b) What is Scaffolding?Explain generic and application specific scaffolding? Dec 2010




It should be generic or specific?

• How general should scaffolding be? To answer

– We could build a driver and stubs for each test case or at least factor out some common code of

the driver and test management (e.g., JUnit)

– ... or further factor out some common support code, to drive a large number of test cases from

data (as in DDSteps) or further, generate the data automatically from a more abstract model (e.g.,

network traffic model)

• A question of costs and re-use Just as for other kinds of software.

7c) Briefly explain Test Oracles? Dec 2010

Test Oracles


must be checked by hand!Range of specific to general, again, ex. JUnit: Specific oracle



(“assert”) coded by hand in each test case Typical approach: “comparison-based” oracle with

predicted output value ,Not the only approach!

An oracle can also be written as self-checks -Often possible to judge correctness

UNIT - 7


7a) Explain Adequacy Criteria? July 2011

Soln:

TEST ADEQUECY

• Adequacy criterion = set of test obligations • A test suite satisfies an adequacy criterion if – all

the tests succeed (pass)

– Every test obligation in the criterion is satisfied by at least one of the test cases in the test suite.

Example: the statement coverage adequacy criterion is satisfied by test suite S for program P if

each executable statement in P is executed by at least one test case in S, and the outcome of each

test execution was “pass”. Sometimes no test suite can satisfy a criterion for a given program –

Example: Defensive programming style includes “can’t happen” sanity checks

if (z < 0) { throw new LogicError( “z must be positive here!”) }

No test suite can satisfy statement coverage for this program (if it’s correct) Test adequacy

criteria is useful to Test selection approaches,Guidance in devising a thorough test suite.

• Example: A specification-based criterion may suggest test cases covering representative

combinations of values Revealing missing tests,Post hoc analysis: What might I have missed

with this test suite?

• Often in combination

– Example: Design test suite from specifications, then use structural criterion (e.g., coverage of

all branches) to highlight missed logic Adequacy criteria provide a way to define a notion of

“thoroughness” in a test suite But they don’t offer guarantees; more like design rules to highlight

inadequacy.

• Defined in terms of “covering” some information Derived from many sources: Specs,

code, models, ...

• May be used for selection as well as measurement With caution! An aid to thoughtful

test design, not a substitute

7b) Explain Test Oracles with neat diagram? July 2011

Soln:

Test Oracles




must be checked by hand! Range of specific to general, again, ex. JUnit: Specific oracle

(“assert”) coded by hand in each test case Typical approach: “comparison-based” oracle with

predicted output value ,Not the only approach!

An oracle can also be written as self-checks -Often possible to judge correctness

7c) What is Scaffolding?Explain Jun 2011

Code produced to support development activities (especially testing), Not part of the

“product” as seen by the end user May be temporary (like scaffolding in construction of

buildings Includes Test harnesses, drivers, and stubs.

• Test driver

– A “main” program for running a test



• May be produced before a “real” main program

• Provides more control than the “real” main program

– To driver program under test through test cases

• Test stubs

– Substitute for called functions/methods/objects

• Test harness

– Substitutes for other parts of the deployed environment

• Ex: Software simulation of a hardware device

UNIT - 7


7 a) Define Test Case,Test case Specification,Test Suite,Adequacy Criteria,Test Obligation?

Soln:


• Test case specification: a requirement to be satisfied by one or more test cases.


thorough testing.





• Adequacy criterion: a predicate that is true (satisfied) or false (not satisfied) of a _program,

test suite_ pair.

7b) What is scaffolding?Explain briefly Generic and specific scaffolding? Dec 2011




It should be generic or specific?

• How general should scaffolding be? To answer We could build a driver and stubs for each test

case or at least factor out some common, code of the driver and test management (e.g., JUnit) . or

further factor out some common support code, to drive a large number of test cases from data (as

in DDSteps) or further, generate the data automatically from a more abstract model (e.g.,

network traffic model) A question of costs and re-use, Just as for other kinds of software.

UNIT - 8

PROCESS

8a) Write short notes on a) Quality process b) Integration Testing c) Component based Testing d)

Component integration Jun 2010

Soln:

a)Quality process: set of activities and responsibilities,focused primarily on ensuring adequate

dependability,concerned with project schedule or with product usability,The quality process

provides a framework for selecting and arranging activities considering interactions and trade-

offs with other important goals.

b)Integration testing is a systematic technique for constructing the program structure while

conducting tests to uncover errors associated with interfacing. Once all the individual units have

been tested there is a need to test how they were put together to ensure no data is lost across



interface, one module does not have an adverse impact on another and a function is not

performed correctly. Integration testing is a systematic approach that produces the program

structure while at the same time producing tests to identify errors associated with interfacing.

c)Not primarily to find faults in the component

• Major question: Is the component suitable for this application?

– Primary risk is not fitting the application context:

• Unanticipated dependence or interactions with environment• Performance or capacity limits

• Missing functionality, misunderstood API

– Risk high when using component for first time

• Reducing risk: Trial integration early

– Often worthwhile to build driver to test model scenarios, long before actual integration.

d)First: Thorough unit and subsystem testing

– Includes thorough functional testing based on application program interface (API)

– Rule of thumb: Reusable component requires at least twice the effort in design,

implementation, and testing as a subsystem constructed for a single use (often more)

• Second: Thorough acceptance testing

– Based on scenarios of expected use

– Includes stress and capacity testing

• Find and document the limits of applicability.



UNIT - 8

PROCESS

8) Write Short Notes on a) Integration b) System c)Acceptance d) Regression Dec 2010

a) Integration testing is a systematic technique for constructing the program structure while






b) Ultimately, software is included with other system components and a set of system

validation and integration tests are performed. Steps performed during software design and

testing can greatly improve the probability of successful software integration in the larger

system. System testing is a series of different tests whose main aim is to fully exercise the

computer-based system. Although each test has a different role, all work should verify that all

system elements have been properly integrated and form allocated functions. Below we consider

various system tests for computer-based systems.

c) Integration, system and acceptance testing to the quality team but the development team may

produce scaffolding and oracles

d) Each time a new model is added as a part of integration testing, the software changes. New

data flow paths are established, new I/O may occur, and new control logic is invoked. These

changes may cause problems with functions that previously worked flawlessly. In the context of

an integration test, strategy regression testing is the re-execution of subset of tests that have

already been conducted to ensure that changes have not propagated unintended side effects.



UNIT - 8

PROCESS

8a) Explain in detail Integration Testing strategies? Describe use of integration testing in detecting

Memory leaks? July 2011

Soln:

There is often a tendency to attempt to construct the program using a “big bang” approaches. All

modules are combined in advance. The entire program is tested as a whole. And chaos usually

results! A set of errors is encountered. Correction is difficult because isolation of causes is

complicated by the vast expanse of the entire program. Once these errors are corrected, new ones

appear and the process continues in a seemingly endless loop.

Top-Down integration

Top-down integration is an incremental approach to the production of program structure.

Modules are integrated by moving downwards through the control hierarchy, starting with the

main control module. Modules subordinate to the main control module are included into the

structure in either a depth-first or breadth-first manner. Relating to the figure below depth-first

integration would integrate the modules on a major control path of the structure. Selection of a

major path is arbitrary and relies on application particular features. For instance, selecting the

left-hand path, modules M1, M2, M5 would be integrated first. Next M8 or M6 would be

integrated. Then the central and right-hand control paths are produced. Breath-first integration

includes all modules directly subordinate at each level, moving across the structure horizontally.

From the figure modules M2, M3 and M4 would be integrated first. The next control level,

M5,M6 etc., follows.



b) Describe System and Acceptance testing? July 2011



UNIT - 8

PROCESS

8) Write Short notes on ) Integration b) System c)Acceptance d) Regression Dec 2011

a) Integration testing is a systematic technique for constructing the program structure while






b) Ultimately, software is included with other system components and a set of system

validation and integration tests are performed. Steps performed during software design and

testing can greatly improve the probability of successful software integration in the larger

system. System testing is a series of different tests whose main aim is to fully exercise the

computer-based system. Although each test has a different role, all work should verify that all

system elements have been properly integrated and form allocated functions. Below we consider

various system tests for computer-based systems.

c) Integration, system and acceptance testing to the quality team but the development team may

produce scaffolding and oracles

d) Each time a new model is added as a part of integration testing, the software changes. New

data flow paths are established, new I/O may occur, and new control logic is invoked. These

changes may cause problems with functions that previously worked flawlessly. In the context of

an integration test, strategy regression testing is the re-execution of subset of tests that have

already been conducted to ensure that changes have not propagated unintended side effects.

Question Paper Solution - e-Learning · project Examples: - The ratio of actual to expected system...

Documents

Transcript of Question Paper Solution - e-Learning · project Examples: - The ratio of actual to expected system...